Archibus Mobile Security Review

Archibus Mobile: Security Review for Reservations

Applications Used for Making Reservations

  1. Archibus Workplace (Mobile Browser)
    1. Browser-based
    2. Does not cache user information, nothing is downloaded (confirmed with Archibus in writing)
    3. Desktop or Mobile browsers
    4. SSO login, 2nd factor authentication when not on Stanford/LPCH network
    5. HTTPS connection – secure data transfer
    6. Licensing: self-service licenses (PACPs)
  2. Archibus Mobile App
    1. Downloaded application
    2. Downloads data locally to a SQLite database on the mobile device
      1. No option to operate app fully online, requires local storage (confirmed with Archibus)
      2. Data encryption at rest in SQLite database – implemented and tested in development
        1. https://www.archibus.net/ai/abizfiles/v26.1_help/archibus_help/system/sysman.htm#J2EE/General_Configuration_Options.htm#Enabling
      3. Tables downloaded
        1. https://www.archibus.net/ai/abizfiles/v25.4_help/archibus_help/system/sysman.htm#mobile/core/apps_sync_tables.htm?TocPath=Mobile%2520Apps%2520Administrator%257CUser%2520Interface%2520Extensions%257CSynchronization%257C_____5
      4. VPA – Restricting users
        1. Assigned by role
      5. Fields downloaded
        1. For the Mobile Client, the list of fields synced by each “common” table is stored within per-table files in \archibus\schema\ab-products\common\mobile\src\Common\model\
        2. EM syncs em_id, email, bl_id, fl_id, rm_id, phone, name_last, name_first, em_number, dv_id, dp_id, em_std, and em_photo
        3. Entire Fields can be blocked from being downloaded using an Archibus security group, but we can only block fields that are not required by the application: em_number, em_photo, em_std, phone are likely but other fields may be able to be removed but need to be validated with testing.
          1. Downside:

The fields that are possible to be blocked may change if you use other modules in mobile or in future versions.

Hiding the fields by security group is application-wide so would need to confirm that users also don’t need the fields in workplace, and would not be able to do for Archibus admin users

          1. Another option to hide: customize the code

Downside: There would be a cost and it would need to be brought forward with every upgrade

        1. Data can be blocked from being downloaded to restrict the number of records (performance) or type of records (ex: not download LPCH employees) by implementing a VPA restriction. This restriction is also application-wide and would not be able to be implemented for Archibus admin roles who need access to all records.
    1. Mobile only
    2. SSO login, 2nd factor authentication
    3. HTTPS connection – secure data transfer
    4. Licensing: self-service licenses (PACPs)

Security Concerns

  1. Data Stored Locally on insecure non-Stanford device
    1. Main concern: employee data on could be used in phishing

Additional Concerns

  1. Employee images were recently loaded which makes syncing with the app much slower
    1. Ways to block employee photo download:
      1. We could use a security group for the photo field to block download of field, but it would also block employee image from workplace and would not block it for Archibus admin users who would need to see the field to load in Web Central (change is application-wide)
      2. Mobile customization to not download employee photo

Recommendations

  1. With data at rest encryption turned on we still think this is an acceptably secure solution.
  2. That said, because data storage locally at all has been identified as not an acceptable risk by Stanford, we believe that users should use the Archibus Workplace application. It provides all the functionality that is required and does not require data downloading.

Was this helpful?

0 / 0

Leave a Reply 0

Your email address will not be published. Required fields are marked *