Low Code Solutions

Policies

Policies

Information Security: Minimum Security Requirements

  1. Policy Purpose:

    The purpose of this policy is to establish specific minimum standards for securing all Betty Blocks applications built on the University of Wisconsin-Madison tenant. This policy is designed to ensure that the UW appropriately safeguards data and account-based access to information assets.

  2. Purpose of Procedures

    This document describes the minimum-security requirements that must be met by applications created within the UW tenant of Betty Blocks to be used at UW-Madison and the University of Wisconsin (UW) System institutions.

  3. Responsible Parties

    The application developers, service team leads and organization administrators per the Low Code Solution’s Terms of Service who review the applications prior to setting the application live. The application developers who make any changes to the application after it initially was reviewed and made live.

  4. Scope

    This policy applies to all applications* created using UW’s Betty Block tenant.

    *These minimum security requirements are intended for applications that do not contain HIPAA/PHI. Additional criteria as defined during the application’s Cybersecurity review will also need to be met for applications that do contain HIPAA/PHI data.

  5. Background

    UW-Madison and the Low Code Solutions’ team is committed to a secure information technology (IT) environment in support of UW’s mission. This policy is designed to help ensure applications are created in such manner to uphold data and authentication standards consistent with UW System.

  6. Definitions

    1. Manifest – Manifest Getting Started

  7. Procedures

    1. Application Standards

      1. Only UW and UW Org Templates may be used to build low code solutions that move to production

    2. Authentication

      1. Use Single Sign On (SSO) authentication for every page requiring protection of data unless it needs to be a public facing page such as a login or information page.
      2. Set the Default Authentication Profile (Tools>Application Settings) for your application to use SSO.
      3. For guidance on making the determination about the classification of your data, refer to: Information Security Data Classification and Protection
      4. Set roles in your UW application using Manifest.
      5. For applications that only allow Manifest users, set the default role in Betty Blocks to mirror the lowest permissioned group in Manifest.
      6. Authentication timeouts should be set to 1800 and 43,200 to follow UW System authentication re-authentication requirements.

    3. Authorization

      1. Create at least one role in the Tools>Roles and Permissions application settings that is not the default Public or Admin role. Your users should be assigned this role, even if you have no other roles necessary in your project requirements.
      2. Create clear documentation for the purposes of the roles in your application.
      3. Every private page should include a role authorization data container specifying which role can access it.
      4. Set up data model read access for each role to limit access to only those models that the role should be allowed to access.
      5. Authorization should be done via role and not directly to a specific user.

    4. Actions

      1. All actions should be private and restricted to an authentication profile except actions for SSO login or actions triggered from a public page.
      2. Scheduled actions should be private.
      3. Set permission on actions to allow execution for only the user role(s) that need to run them.
      4. Application Programming Interface (API) calls in actions require special security consideration. Please refer to the API subsection for specific recommendations.
      5. If you need to capture and store the userID or name of a user executing an action, use the current webuser property variable inside the action to capture the logged-in user’s data. This prevents someone from changing the username value in a POST request.
      6. When populating fields in actions that require passwords/key or other sensitive values use App Configurations with encryption turned on to protect those values.

    5. Data Models

      1. Each data model should have restrictions set in the configuration on the user roles that can access it.
      2. Include at least one required property in a data model to prevent blank records.
      3. Add validations to all required properties in a data model.
      4. No Data Model should be readable by the built-in public role.

    6. Data API

      1. No public access to a data model via the Data API.
      2. All data API access should be secured via a custom Authentication Profile. Betty Blocks Platform Accounts should not be used to access the Data API.
      3. Any internal, sensitive or restricted data (Data Classifications) being extracted by the Data API is subject to Data Stewards and must go through a review by Cyber Security and or Compliance offices to ensure the proper handling of the data.

    7. Pages

      1. Include a page-level authorization data container with a nested role data container (filtered to the current webuser) on top of every private page.
      2. Set redirects on the page-level data containers to stop those without approved roles from accessing a page.
      3. Use the Advanced option on authorization and role Data Containers to hide child objects when there is no data to display.
      4. To protect against guessing or indexing through unauthorized datasets or records via input page variables. Use Universally Unique Identifier (UUID)s to uniquely identify the record instead of the model’s ID when passing them in URLs. (reference the best practices for models and actions)
      5. Page input variables are displayed in the URL as a “Query Parameter”. Information being passed between pages via input variables must not include any sensitive or restricted data
      6. When using conditionals for role-based display (showing or hiding data elements based on a role or value), put objects that should not be accessed inside the conditional block, so they don’t render in the browser.
      7. Regarding showing or hiding components on a page, only hide/show low security items as the hidden elements can still be seen by viewing the source code of the page.
      8. Do not use the hidden input field to contain security or confidential data. The hidden field value is visible to anyone who views the source of the page or uses the browser tools to examine the page contents.
      9. ReCAPTCHA should be used on any public form submissions.

    8. API (External Data Source) Usage

      1. All data API calls must be authenticated.
      2. All Credentials used to connect external sources to Betty Blocks should be unique to that application and not reused or shared with other applications.
      3. All external data source usage must be approved by the appropriate data steward(s).

    9. Miscellaneous

      1. Carefully remove unused roles/pages/actions. (best practice for not leaving old or test pages accessible)
      2. Do not trust configurations to be encrypted. They are currently accessible via all actions in plain text – with possible other ways to log them.

  8. Related Documents

    1. LCS – Best Practices
    2. LCS – ReCAPTCHA setup in Betty Blocks
    3. Content Security

  9. History

    Revision 1: 5/6/2024

Return to Top

Privacy Policy

UW-Madison respects the legitimate privacy interests of all Low Code Solutions users within appropriate limits for educational, ethical and legal reasons.

Usage may also be subject to security testing and monitoring.

If the university receives a credible report that a violation has occurred, or if, in the course of managing the service, discovers evidence of a violation, then the matter will be referred for investigation, university disciplinary action, and/or criminal prosecution.

Complaints that specific material violates the law or university policy should be reported to the Office of Cybersecurity via their Reporting an Issue to the Office of Cybersecurity Form or abuse@wisc.edu.

If you are employed by the university, you should be aware that any documents or data that you publish, save, or collect in a Low Code Solutions application may be subject to the Wisconsin Open Records Act. For more information on Records Management, please go to Legal Requirements for University Records.

Return to Top