TRA Business Rule Index

The TRA Business Rules Index contains links to Business Rules and Recommended Practices that are referenced in each section of the CMS TRA. Retired, deprecated, and withdrawn rules (when shown) show the text of the last TRA version that contained them. Any rationales and explanations can be found in the archived version in the CMSShare TRA page.

Foundation

Foundation Business Rules
Rule ID Rule
BR-F-1 Any Deviations from the CMS TRA Must Be Requested and Approved
BR-F-2 The CMS TRA Applies to All CMS Processing Environments
BR-F-3 The CMS TRA Defines a Zoned Architecture
BR-F-4 Within a CMS Processing Environment, Communication Must Flow Only between Adjacent Zones or within a Single Zone
BR-F-5 Any System That Processes CMS Data Must Be Covered by a CMS ATO
BR-F-6 Mainframes Must Be Dedicated to CMS
BR-F-7 Cost-Effective Reuse of Data Centers with Established TIC, CMSNet, and CCIC Integration
BR-F-8 Backup CMS Data
BR-F-9 Test CMS Backups on a Documented Schedule
BR-F-10 Annual Review and Exercise of Data Center Disaster Recovery Plans
BR-F-11 Annual Review and Exercise of Contingency Plans
BR-F-12 Role-Based Security AAA Must Be Used for Management and User Roles
BR-F-13 Consistent Security Categorization within ARS Security Boundary
BR-F-14 Applications with Disparate FIPS-199 Security Categorization Levels Must Not Be Hosted on the Same Server
BR-F-15 Ensure Timely Version, Patch, and Configuration Management Practices
BR-F-16 All Hosts Must Share a Common Authenticated Time Server
BR-F-17 The CMS TRA Applies to Custom-Produced as well as COTS Products and Services
BR-F-18 Use .Gov Domain Names for All CMS Internet Traffic
BR-F-19 Communication Initiated to Internet-Based Services from ATO’d Environments Must Be Allowlisted
BR-F-20 Untrusted Services and Code from Third-Party Websites and Applications
RP-F-21 Limit Data in the Application and Presentation Zones
BR-F-22 The CMS TRA Defines a Services Framework Architecture

Infrastructure Services

Infrastructure Services Business Rules
Rule ID Rule
BR-SV-1 Apply Separation of Duties to Virtualization Administration
BR-SV-2 Provide Hypervisor Root Access Only to Specific Administrative Accounts
BR-SV-3 Different Administration Account on Blade Controllers and Hypervisors
BR-SV-4 Configure UserIDs and GroupIDs to Be Unique across the Processing Environment
RP-SV-5 Maintenance Window Planning
RP-SV-6 Consider High-Availability Configuration
BR-SV-7 No Co-Hosting on Production and Non-Production Hypervisors
BR-SV-8 Do Not Oversubscribe ATO(ed) Environments and Management Zones
BR-SV-9 Use Storage Quotas for Virtual Machines
BR-SV-10 ATO(ed) Environment VMs and Resource Pools Must Not Be Shared between Zones
RP-SV-11 Collect Virtualization Performance Metrics
BR-SV-12 Perform Asset Management of Virtual Instances
BR-SV-13 Keep Forensic Evidence per CMS Security Rules
RP-SV-14 Use VM Configuration Templates
BR-SV-15 Production Management Zone VMs May Not Use IP Multipathing
BR-SV-16 Originate Administrator Access to Blade Controllers and Hypervisors from the Management Zone
BR-SV-17 All Management Traffic Must Originate or Terminate in the Management Zone and Use Only Isolated and Protected Interfaces
BR-SV-18 Hypervisor Access Is Permitted Only Via the Management Interface
BR-SV-19 Separate Security Segment from All Other Management Zone Segments
BR-SV-20 Oversubscription of Non-Production Instances Is Permitted
BR-SV-21 No Business Applications May Run on the Hypervisor’s Host OS
BR-SV-22 Operate Applications under Application-Specific System Accounts
BR-NV-1 Use Highly Available Network Services to Implement Zone Separation
BR-MV-1 z/VM Sole Configuration
BR-MV-2 z/Linux as Sole Guest for z/VM
BR-MV-3 No Nested z/VM Instances
BR-MV-4 Multiple Zones for a Single Application
BR-CI-1 Choosing a Cloud Deployment and Service Model
BR-CI-3 Document the Impact of Cloud Deployment
BR-CI-4 Engage TRB Consulting for CMS-Owned Equipment
BR-CI-5 Acquisition of New IaaS or PaaS Cloud Service Providers
BR-CI-6 Define Data Backup and Contingency Plans in a Cloud
BR-CI-7 Cloud Resource Capacity Planning
BR-CI-8 Separate Production, Management, and Non-Production Resource Clusters
BR-CI-9 Applicability of Multi-Zone Architecture
BR-CI-11 Cloud Services Covered by a CMS ATO May Be Used in Lieu of Virtual Network Elements
BR-PMM-1 Performance Monitoring Data Is FOUO
BR-PMM-2 Control Access to Performance Monitoring Data
BR-PMM-3 Monitor Production Environments
RP-PMM-1 Coordinate Application Changes with Monitoring Operations
RP-PMM-2 Consider Monitoring Lower Environments
RP-PMM-3 Provide Performance Data to CMS NOC
RP-PMM-4 Conduct Performance Management Planning
RP-PMM-5 Use a Trouble Ticketing System to Track Performance Problems
RP-PMM-6 At Least One End-to-End Test
RP-PMM-7 Identify Un-Monitorable Components as a Risk
RP-PMM-8 Support Standards-Based Tools
RP-PMM-9 Define Services in a Service Catalog
BR-SAAS-1 SaaS Clouds Are Defined by NIST SP-800-145
BR-SAAS-2 SaaS Must Have a CMS ATO
BR-SAAS-3 Ensure CMS Security May Perform Periodic Security Assessments
BR-SAAS-4 Plan for Data Archival to Comply with Federal Records Management
BR-SAAS-5 Establish SaaS-Specific Contingency Program
BR-SAAS-6 Perform Configuration Management
BR-SAAS-7 Integrate with CMS CCIC
BR-SAAS-8 CMS Data Must Always Reside in the U.S.
RP-SAAS-1 Integrate with CMSNet
RP-SAAS-2 Comply with CMS Defense-in-Depth Architecture
RP-SAAS-3 Continuous Monitoring
RP-SAAS-4 Integrate SaaS with CMS Identity Management Systems
BR-KSM-1 KSM Auditing Must Be Enabled and Connected to CMS Logging Infrastructure
BR-KSM-2 KSM Must Use RBAC with Separate Roles by CMS Application Environment
BR-KSM-3 Ensure the KSM Has Sufficient Availability for Your Applications
BR-KSM-4 Audit Logs for Credential Leaks
RP-KSM-1 Applications Should Use a KSM to Manage Keys and Secrets
RP-KSM-2 Configure Applications to Use Dynamic Credentials
RP-KSM-3 Consider Credential Injection into VM Images during Startup
BR-MD-1 Mobile Devices (GFE and non-GFE) Must Be Authorized to Access CMS Systems and Government Data
BR-MD-2 Mobile Devices Must Use Encrypted Communication to Access CMS Data
BR-MD-3 Managed Mobile Devices Must Support Remotely Erasing All Stored Data If the Device Is Lost, Stolen, or Compromised
BR-MD-4 Managed Mobile Devices Must Support Encryption for Internal and Removable Storage
BR-MD-5 Managed Mobile Devices Must Meet CMS Security Requirements
BR-MD-6 Only CMS Authorized Applications May Be Installed on CMS-Managed Devices
BR-MD-7 User Agreements Must Be In Place for Mobile Devices Accessing CMS Services and Data
BR-IoT-1 CMS IoT Platforms Must Comply with CMS Requirements for CMS Processing Environments
RP-IoT-1 CMS-Managed IoT Devices Should Comply with NIST SP 1800-15 and the Latest MUD Specifications
BR-DR-1 Annual Review of Disaster Recovery Plans
BR-DR-2 Disaster Recovery Tier Selection
BR-DR-3 All CMS FISMA systems must have a plan for DR
BR-DR-4 Required Risk Analysis, System BIA, and ISCP
BR-DR-5 Number of Disaster Recovery Tiers

Application Development

Application Development Business Rules
Rule ID Rule
BR-ADM-1 Use of the CMS Life Cycle Is Mandatory
BR-ADM-2 The Development Methodology and Artifacts Must Be Documented
BR-SA-1 Use CMS Shared Services
BR-SA-2 Integrate with the CMS Identity Management Services
BR-SA-3 No Custom Application Code Is Permitted in the Presentation Zone
BR-SA-4 Use CMS-Validated Mediation and Data Access Services to Access Data in the Data Zone
BR-SA-5 No Long-Term, Persistent Sensitive Application Data Storage in the Presentation or Application Zones
BR-SA-6 Network Communications Must Meet the TRA Rules for Encryption
BR-SA-7 Substantive Changes to the Architecture, Products, or Technology of an Existing Application Must Be Documented and Reviewed by the CMS TRB
BR-SA-8 Logging Must Be Configurable and Use Common Platform Standards
BR-SA-9 Systems Must Define Metrics for IT Health Monitoring
BR-SA-10 Applications in CMS Data Centers May Not Use Some Native Email Protocols
RP-SA-11 Servers Should Include Instrumentation for Application Performance Monitoring
RP-SA-12 Minimize Manual File Copying by Using Integrating File Transfer Automation
RP-SA-13 Consider Data Services in the Data Zone to Improve Performance of Database-Intensive Services
BR-SA-14 Use of Short Message Service / Multimedia Message Service by CMS Applications
BR-SA-15 Protect Sensitive Information in Transit
BR-SA-16 Protect Sensitive Information at Rest
BR-SD-1 External Configuration Is Mandatory
BR-SD-2 Web-Based User Interfaces Must Comply with TRA Guidance
RP-SD-3 Configurations Should Be Validated and Checked on Each System Startup
RP-SD-4 Consider Dependency Injection to Achieve External Configuration
RP-SD-5 External System Dependencies Should Be Stubbed Out for Development and Testing
RP-SD-6 Timestamps Logged by the System Must Be in UTC or GMT and Should Be Expressed in ISO-8601 Format
RP-SD-7 Software Should Be Designed Based on SOA Principles
RP-SD-8 Consider Non-Blocking Service Implementations to Improve Performance and Scalability
BR-SC-1 Inventory all Open Source Software Licenses
BR-SC-2 All Custom-Written Source Code for a Project Must Conform to an Identified Coding Standard
RP-SC-3 Do Not Intermingle Code in Different Programming Languages in the Same File
RP-SC-2 Capture Code Metrics and Defect Tracking Metrics for Quality Improvement Purposes
RP-SC-5 When Using Flat Files for Data Transfer, Include Helpful Metadata in the File
RP-SC-6 When Using Flat Files for Data Transfer, Consider Including a Machine-Readable Schema
RP-SC-7 Use Decimal Math Types for Financial Calculations
RP-SC-8 Consider Synthetic Transactions
BR-SQ-1 All Custom-Written Software Must Have Associated Automated Unit Tests
BR-SQ-2 Run Automated Unit Tests during Full Builds
BR-SQ-3 Automated Unit Tests Must Use a Commercially Available Unit Testing Framework or Test Runner
BR-SQ-4 All CMS User Interfaces Must Meet Section 508 Accessibility Requirements
BR-SQ-5 Manual Code and Design Reviews Are Mandatory
BR-SQ-6 De-Identification of Production Data Is Required in Non-Production Environments
RP-SQ-7 Code Coverage Analysis Is Highly Encouraged During Unit Testing
RP-SQ-8 Use Static Analysis Tools During Build to Catch Common Coding Errors
RP-SQ-9 Developers Assist Testers in Generating Test Data
BR-SS-1 All Software on CMS Production Servers Must Have Recorded Provenance
BR-SS-2 Use NIST SP 800-132-Specified Salted Hashes to Store Passwords
BR-SS-3 SQL Code Must Use Binding Variables
BR-SS-4 Check for Common Security Vulnerabilities
BR-SS-5 Use Static Analysis Tools to Catch Common Security Weaknesses
RP-SS-6 Use Profiling to Perform Dynamic Code Analysis
BR-SS-7 Error Handling Must Not Reveal Information That Could Lead to an Exploit
RP-SS-8 Perform Threat Modeling During the Design Phase to Identify Potential System Threats
BR-ED-1 Custom-Written Software Must Include Inline Documentation for Public APIs
BR-ED-2 The CMS TLC Phase Review Artifacts Must Be Produced
RP-ED-3 Engineering Documentation Should Be Versioned Along with Source Code in the Same Repository
RP-SM-1 Consider Building Self-Diagnosis Capability into Systems
RP-SM-2 Consider Designing Maintenance Capability into Systems
BR-DBM-1 Systems Must Meet Federal Record Management Requirements
BR-DBM-2 Systems Must Meet Federal Government FOIA Requirements
BR-DBM-3 Systems Must Meet CMS Data and Database Management Standards
BR-SCM-1 All Source Code Must Be Checked in to Version Control
BR-SCM-2 All Code Must Be Baselined Prior to Release into Implementation, Validation, and ATO(ed) Production Environments
RP-SCM-3 Apply Database-Oriented Configuration Management Practices
BR-SCM-4 Configurations Must Be Checked in to Version Control
BR-DIT-1 All CMS Software Development Projects Must Use a Defect Tracking System
BR-DIT-2 A Defined Defect Classification Standard Is Mandatory
RP-DIT-3 Defects Should Be Correlated to Baselines
BR-SBI-1 All Builds Must Occur in Controlled Environments
BR-SBI-2 All Production-Deployed Custom Code Must Be Built and Installed from Version-Controlled Source Code
BR-SBI-3 Production Builds Must Have Zero Compile Errors
RP-SBI-4 Use Explicit Library and Build Dependency Management
RP-SBI-5 Consider Instituting Continuous Integration
BR-PD-1 Software Must Be Packaged for Deployment
BR-PD-2 Software Target Packaging Must Be in Either the Operating System or Language Platform Native Form
BR-PD-3 Database Changes Must Include Back-Out Scripts
RP-PD-4 The Package Manifest Should Include a List of All Defects Corrected in the Release
RP-PD-5 Changes Applied to Databases Should Be Recorded in the Database Itself
RP-PD-6 Support A/B Testing of User Interfaces
BR-D-1 Developers Do Not Have Unsupervised Administrative Access to Production Servers
BR-D-2 All Installation and Back-Out Scripts Must Have Been Tested in Lower Environments Prior to Use in Production
RP-D-3 Support Rolling Deployment
RP-D-4 Use Feature Flags to Gradually Introduce New Features to Users
RP-D-5 Deployment Should Integrate with Monitoring to Coordinate Outages
RP-D-6 Support Rollback of Package Installation
RP-D-7 Support Automated Startup, Shutdown, and Maintenance Mode Entry / Exit
RP-RM-1 Establish and Follow Organizational Standards for Deployment of Custom Software
BR-WS-1 Describe All Services
BR-WS-2 Services Must Use Standard Invocations
BR-WS-3 Services Must Validate Input and Outputs
BR-WS-4 Use TRB-Approved Data Zone Mediation and Data Access Services to Access Data in the Data Zone
BR-WS-5 Messages Must Include Timestamp and Originator
BR-WS-6 Services Must Use Open Data Formats
BR-WS-7 Web Services Must Follow CMS Encryption Policy
BR-WS-8 SOAP-Based Services Must Comply with WS-* Standards
BR-WS-9 Inter-Zone Web Services Must Transverse a Mediated Service
BR-WS-10 Web Services Must Be Version Numbered
BR-WS-11 Use Certificate-Based Mutual Authentication for Machine-to-Machine Web Services
BR-WS-12 Messages Must Pass through All Intermediate Zones
BR-WS-13 CMS Public APIs Must Be Published
BR-UX-1 Ensure Usability and Accessibility
BR-UX-2 Collect Feedback
BR-UX-3 Provide Multilingual Capability
BR-UX-4 Ensure Privacy and Security
BR-UI-5 Skip Navigation
BR-UI-6 Provide a Home Page Link
BR-UI-7 No Frames
BR-UI-8 Keyboard and Mouse
BR-UI-9 Phishing and Redirection Prevention
BR-UI-10 Cross-Site Request Forgery Prevention
BR-UI-12 Authentication
BR-UI-13 Session Management
BR-UI-14 Protecting PHI
BR-UI-15 User Identifiers
BR-UI-16 Input Validation
BR-UI-18 Need to Disclose
BR-UI-19 Color Contrast Ratio
BR-UI-25 Scripts Compatibility
BR-OSS-1 Products in Use at CMS that Provide the Required Functionality Are Preferred
BR-OSS-2 Criteria for Evaluation
BR-OSS-3 Total Cost of Ownership
BR-OSS-4 License Compatibility for Using OSS
BR-OSS-5 Use OSS Built from a Controlled Source
BR-OSS-6 Binary Package Management Is Mandatory
BR-OSS-10 CMS OSS Code Released as CMS-Managed Code Requires a Governance and Support Model
BR-OSS-11 CMS OSS Code Released as Unmanaged Code Must Be Identified as Such
BR-OSS-12 CMS-Released OSS Code Must Include Automated Unit Tests, Build Scripts and Be Checked for Software Vulnerabilities
BR-OSS-13 CMS-Released OSS Code Must Include Documentation Accessible to the Open Source Community
BR-OSS-14 Use the CMS’s External GitHub Repository and Code.gov for CMS-Released OSS Code
RP-OSS-1 Provide Ample Documentation with CMS-Released OSS Code
RP-OSS-2 Implement the Tools to Support the Community Around a CMS-Released OSS Project
BR-P-1 Each Portlet Must Include a Deployment Descriptor as Specified in JSR 286
BR-P-2 Each Portlet Must Implement Specific Portlet Life-Cycle Management Functions as Specified in JSR 286
BR-P-3 Each Portlet Must Log Events via Portlet Container Logging Functions
BR-P-4 If Functionality to Customize / Personalize the Portlet User Interface Is Provided, It Must Be Consistent with JSR 286
BR-P-5 Each Portlet Must Control Access to Content / Functionality Based on User and Role Information via the Portal
BR-P-6 Each Portlet Must Use Portal Services to Authenticate Users
BR-P-7 Each Portlet Must Securely Transport Sensitive Content
BR-P-8 Inter-Portlet Communication Must Be Performed Only by Either Public Render Parameters or Events as Specified in JSR 286
BR-P-9 Remote Portlets Must Follow Web Service Standards
BR-CA-1 The CMS Zonal Architecture Must Be Preserved
BR-CA-2 Lower Environments Must Be Separated from Production
BR-CA-3 The CMS TRA Zonal Hierarchy Will Be Enforced
BR-CA-4 Interfaces between the Containers Implemented in Each Zone Must Be Locked Down (Source / Destination)
BR-CA-5 Container Traffic to Non-Container or External Destinations Must Follow Existing TRA Rules
RP-CA-1 Force Containers to Write to Container-Specific File Systems
RP-CA-2 Implement Read-Only File Systems Whenever Possible
RP-CA-3 Run Your Containers as Non-Root Whenever Possible
RP-CA-4 Create Containers with the Least Privilege Possible
RP-CA-6 Use a Security Mechanism for Mandatory Access Controls
RP-CA-7 Use Cgroups
RP-CA-8 Use a Secure Computing Mode Profile
RP-CA-9 Harden All Containers / Components
RP-CA-10 Validate All Third-Party Containerized Applications before Implementation
RP-CA-11 Maintain the Immutability of Your Containers
BR-OR-1 Container Images Must Be Hardened
BR-OR-2 Use Security Monitoring on Containers
BR-OR-3 The Deployment Infrastructure for Containers Must Be Hardened and Monitored
BR-OR-4 Containers Use Must Respect the Multi-Zone Architecture
BR-OR-5 Libraries of Containers Must Be Maintained in CMS-Only Stores
BR-OR-6 Required Orchestration Capabilities
RP-OR-7 Prefer Container Orchestration Tools That Allow for Container Motion
RP-OR-8 Rolling Upgrades
BR-LD-1 Avoid Using Lambda for CMS Sensitive Data
BR-LD-2 Integrate with CMS Enterprise Security
BR-LD-3 Configure Lambda to Control the Cost / Budget
BR-LD-4 Do Not Use the Local Volatile Storage of Lambda Containers for Persistent Data
BR-LD-5 Use Lambda Only for Stateless Transactions
RP-LD-1 Avoid Complex Application Programming or Workflows in Lambda
BR-CM-1 Projects Must Produce a Configuration Management Plan
BR-CM-2 Projects Must Identify Items to Be Placed under Configuration Control
BR-CM-3 Significant Changes to Configuration Items of a System or Component Managed by a CCB Requires the Approval of That CCB
BR-CM-4 Projects Must Maintain Accurate and Reliable CI Information
BR-CM-5 Projects Must Conduct Periodic Audits of CM Activities and Products
BR-CM-6 Projects Must Maintain Configuration Baselines
BR-CM-7 Follow the CMS ARS Hierarchy for Security Configuration

Data Management

Data Management Business Rules
Rule ID Rule
BR-DL-1 CMS TRA Compliance
BR-DL-2 Separation of storage from compute
BR-DL-3 Data assets are not copied or moved
BR-DL-4 Shared data assets are registered in the Hive Metastore and a user-facing data catalog
BR-DL-5 The EDM does not store raw data or unstructured data. All data in the EDM is fully structured and immediately consumable
BR-DL-6 Data sets remain within the data owner’s security boundary
BR-DL-7 Data owners curate their data assets and manage freshness and usability
BR-DL-8 Data consumers bring their own compute resources
BR-DL-9 The data owner determines the users, groups, roles, and policies that govern data access
BR-DG-1 All CMS enterprise data must be stored within a CMS authorization boundary
RP-DG-2 Any CMS enterprise data sharing beyond CMS authorization boundaries should “share-in-place” where feasible, for example, a workspace or a remote API , avoiding file export or replication
BR-EFT-2 Limited Protocols Are Permitted in the CMS EFT System
BR-EFT-3 Use Mailboxes between Business Partners Only
BR-EFT-4 Registration Is Required When Using the CMS EFT System
BR-EFT-5 Internal Integrity Validation Is an Application Responsibility
BR-EFT-6 File Encryption Is an Application Responsibility
BR-EFT-7 Secured Transmission Is Required
BR-EFT-8 IP-Based File Transfer Protocols Only
BR-EFT-10 Encrypt Files Residing in EFT Mailboxes
BR-EFT-11 CMS Data Files May Only Be Transferred to the Data Zone
BR-EFT-12 CMS Data in ATO’d Environments May Not Be Transferred to Non-ATO’d Environments
BR-EFT-13 CMS Data May Not Be Transferred Outside of CMS Processing Environments without a Prior Agreement
RP-EFT-1 Transfer Files Using Check-Pointing Protocols When Performance Impacts Are a Concern [Formerly BR-EFT-9]
BR-DSS-1 Do Not Use UDP for Data Storage Services or File Transfer Services
RP-DSS-2 Use a Trust Relationship or Federation for Authenticated Access to CMS Files
RP-DSS-3 Avoid Unnecessarily Separating Storage Clients and Storage Services into Different Zones
RP-DSS-4 External Storage Services Are External to Any CMS Zone
RP-DSS-5 A Storage Service Data Store Should Not Be Accessible from More Than One Zone
BR-URL-1 Authentication Is Required to Access a Non-Public CMS File Referenced by a URL
BR-URL-2 Authentication and Authorization Are Required to Upload a File to a CMS Location Referenced by a URL
BR-URL-3 Logs Must Identify the Users Who Access a CMS File Referenced by a URL from the External Networks or CMSNet
BR-URL-4 Logs Must Identify the Users Who Upload a File to a CMS Location Referenced by a URL from the External Networks or CMSNet
BR-URL-5 URLs May Not Include Passwords or Decryption Keys
RP-URL-6 Use Signed URLs to Indicate the Source and Creation Time of a CMS File
RP-URL-7 Use Time Limits and/or Click Limits to Control How Long a CMS File Is Available to Unauthenticated External Users for Download through a URL
BR-AWS-1 Encrypt Amazon S3 Data at Rest
BR-AWS-2 The S3 Storage Must Be Attached / Accessible from Not More Than One Zone
BR-AWS-3 Do Not Allow Cross-Zone Access to S3
BR-AWS-4 External Content in S3 Requires a Data User Agreement Process
BR-AWS-5 Users Must Be Authenticated by AWS S3 Using a CMS-Managed IAM Userid When Accessing Data in CMS S3 Buckets
BR-AWS-6 External Data Upload to S3 Is Not Permitted
BR-AWS-7 No Direct Internet Access to an Application’s Main S3 Storage
BR-AWS-8 Remove Data from S3 When They Are No Longer Needed
BR-AWS-9 Remove Unneeded S3 Buckets
RP-AWS-1 Use Amazon AWS Security / Access Features for S3
RP-AWS-2 Use Short-Lived URLs for External Access to S3
BR-BI-1 All Production BI Applications and Systems Must Comply with the CMS TRA and the BI Reference Architecture
BR-BI-3 Authentication, Auditing, and Logging of All BI User Accounts Must Be Managed from the CMS Enterprise LDAP Directory and Enterprise User Administration
BR-BI-4 All Traffic Must Be Encrypted between a BI User’s Browser, Web Services, or Device and the BI Server
BR-BI-5 Role-Based Authorization Must Be Used to Manage Access to BI Applications, Queries, Reports, Analytic Functions, Tables, Views, and Stored Procedures
BR-BI-6 All BI Applications and Systems Must Comply with the Current CMS ARS
BR-BI-7 BI Applications Must Leverage the BI Portal Framework as an Enterprise-Wide Secure Gateway that Enables All BI Tools to Access, Manipulate, and Analyze Data