Get started with Tanium role based access control (#RBAC) in today's tech talk. This will be helpful not only for shops just starting out with Tanium but also for those looking to optimize mature environments.

#informationsecurity #informationtechnology #TaniumRBACSeries

Part 1: https://youtu.be/bpTre9BEh6Q
Part 2: https://youtu.be/pUHBcnOrjsU

RESOURCES
RBAC overview with diagram
https://help.tanium.com/bundle/ug_console_cloud/page/platform_user/console_rbac_overview.html
Module RBAC link list
https://help.tanium.com/bundle/ug_maintenance_cloud/page/maintenance/getting_started.html#configure_RBAC
Tuning Tanium free webinar series
https://community.tanium.com/s/tuning-tanium

CHAPTERS - PART 1

00:00 Intro

00:50 Meet Kat

01:37 RBAC intro

02:35 Users and groups sync

04:27 RBAC overview

05:27 Users into groups

06:47 Docs

07:18 DEMO Content Sets

09:57 DEMO Roles contain permissions

13:00 How do you test permissions?

14:30 DEMO Roles continued

15:00 DEMO Custom Roles

20:39 DEMO Custom Roles and Content Sets

23:51 DEMO Deny Roles

24:38 DEMO Edit multiple custom Roles

26:53 DEMO Cloning Roles

29:30 Wrap up

===SHOW NOTES BELOW===

KNOWLEDGE POINTS
Content sets are like Windows folders that contain assorted objects.
Grant the module role with the highest level of access needed. No need to grant roles with lesser permissions.
Deny roles are only for platform and administration permissions, not modules.
Bulk add permissions across multiple roles.
The "No Computers" group does not deny access. It simply contains no computers.
Computer groups cannot change after they are created.
Filter groups filter the results from endpoints already in the computer groups you have access to.
User groups and computer groups grant cumulative access. Personas entirely change scope of access for mutually-exclusive scenarios..

BEST PRACTICES
If you need to assign permissions to a single user, put them into a group first so that other employees coming and going can get the same permissions when needed.
Put dangerous packages or sensors and packages that are currently being tested into content sets with limited access.
Review RBAC once per year.
Test RBAC by assigning a persona, with the roles and computer groups you want to test, to yourself before assigning it to business unit users or groups.
Naming standards should include a company and/or team prefix.
Grant Administration/Client Status for users who need to see the last time an endpoint was seen
Grant Administration/Bandwidth Throttles to network teams that may need to update throttles.
Be sure to grant Show access when creating a custom role for Module access. Ex: Interact/Show.
Assign content set permissions in bulk when multiple roles need an update.
Edit multiple roles at the same time, for example, when adding a new module to multiple teams
If you need a custom module role, begin by cloning an existing module role and modifying it.
Use dynamic computer groups with custom tags rather than rigid query criteria that could change, because computer group definitions cannot change once created.
DO NOT USE MANUAL COMPUTER GROUPS. Tag the machines instead, and use Custom Tags for the computer group definition.
Create and set a default read-only user group for new users so that they can view but not take action, and then grant them access to a group of test machines for learning.
Admins can create a "break glass" persona for special actions they don't want to accidentally use in the course of normal administration.
Start your RBAC planning around user groups to model security groups and job functions. Then use personas to test.
Accommodate mutually-exclusive permissions needs for the same user by using personas.
Use out-of-the-box roles as much as possible before creating custom roles.

TROUBLESHOOTING
Check Interact's Cached view of results to validate scope of computers for a user's access.
Confirm computers meet the criteria of the computer groups assigned to users.
Confirm that custom roles contain the "Show" permission, especially Interact - Show.