CMS has adopted the following business rules for web-based user interfaces within the CMS environments.
User Experience
This topic presents business rules for building web-based user interfaces (UX).
BR-UX-1: Ensure Usability and Accessibility
The Agency must ensure that all CMS websites are accessible to stakeholders both with and without disabilities. To achieve this, website developers must be aware of and observe the following regulations that require testing to ensure accessibility compliance.
Rationale:
-
Section 508 of the Rehabilitation Act is a federal policy that websites must comply with. Those developing websites for federal agencies, including HHS and CMS, must ensure that all employees and members of the public with disabilities are able to access these websites with ease. Additionally, consult both the CMS Section 508 and HHS versions of 508 guidance.
-
Section 504 of the Rehabilitation Act (also known as Reasonable Accommodation) is defined as “…making existing facilities used by employees readily accessible to and usable by individuals with disabilities…” For additional details, consult HHS’s guidance.
-
According to the Plain Writing Act of 2010, government agencies are now required by law to design websites using plain language so that the public can easily understand the communication. Guidelines are also available from the Federal Plain Language website.
-
According to the Government Paperwork Elimination Act, websites must use electronic forms, electronic filing, and electronic signatures to conduct official business with the public.
-
Testing must be conducted to ensure that websites comply with Section 508 and are accessible. HHS approves the Accenture Digital Diagnostics compliance monitor and Adobe Acrobat Professional 8.0 or higher for testing compliance. The World Wide Web Consortium also provides a list of tools for testing compliance.
Please refer to U.S. Web Design System, digital.gov and the following for more details.
CMS must enable stakeholders and the public to provide feedback about their customer experiences.
Rationale:
-
Online surveys are one mechanism for collecting feedback (e.g., Customer Satisfaction Survey available at: http://www.opm.gov/surveys/services/ Customer.asp). By emailing surveys, pop-up, or web-based surveys, CMS can collect feedback to improve training, simplify processes, and establish metrics. Another alternative is to conduct regular usability testing to collect customer feedback. As Usability.gov indicates, a formal usability laboratory is not always necessary and testing could be performed remotely.
-
Implementing Executive Order 13571, “Streamlining Service Delivery and Improving Customer Service” (April 2011), and Office of Management and Budget (OMB) Memorandum M-11-24 requires agencies to set service standards and use customer feedback to improve the customer experience. Please refer to these documents at https://www.digitalgov.gov/resources/executive-order-13571-streamlining-service-delivery-and-improving-customer-service/. Also refer to the American Customer Satisfaction Index for seeking feedback (http://www.theacsi.org/).
BR-UX-3: Provide Multilingual Capability
CMS must provide multilingual capability when foreign language content (i.e., non-English language content) is available. HHS prescribes that links to foreign language materials must be presented as a link written in that language (i.e., En Español, not In Spanish). Another option is to have a clickable En Español option. Thus, when the user clicks on it, the website is made available in another language, as in the following example from HHS:
-
Healthy Heart
-
Also available en Español, Français, Tiếng Việt
Rationale:
-
According to Executive Order 13166, “Improving Access to Services for Persons With Limited English Proficiency” (http://www.justice.gov/crt/about/cor/Pubs/eolep.pdf), federal agency websites must provide access to people who are limited in their English proficiency. For guidance on this, consult HHS’s “Presenting Links to Materials in Multiple Languages” (https://webstandards.hhs.gov/standards/13) or the Title VI Resolution Agreement between HHS and the State of Hawaii Department of Human Services (http://www.hhs.gov/ocr/civilrights/activities/agreements/hawaiiagree.html).
BR-UX-4: Ensure Privacy and Security
CMS must ensure its stakeholders’ privacy and security on all Agency websites. This includes complying with the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Although CMS allows the collection of user information, no Personally Identifiable Information can be collected from simply browsing CMS websites. CMS websites must also comply with the CMS Information Security Acceptable Risk Safeguards (ARS).
Specific related ARS controls include PT-2 - Authority to Process Personally Identifiable Information, PT-3 - Personally Identifiable Information Processing Purposes, PT-4 - Consent, PT-5 - Privacy Notice, and PT-6 - System of Records Notice.
Rationale:
-
Federal public websites must comply with existing laws and directives that address the need to protect the privacy of the American people when they interact with their government. For additional details, please refer to https://www.usa.gov/policies and https://www.digitalgov.gov/resources/checklist-of-requirements-for-federal-digital-services/.
-
Two 2006 NIST standards on information security and personal identification also should be consulted: “Minimum Security Requirements for Federal Information and Information Systems” (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf) provides information on how to secure an online system. “Personal Identity Verification for Federal Employees and Contractors” (http://csrc.nist.gov/publications/fips/fips201-1/FIPS-201-1-chng1.pdf) provides information on how to verify federal employees’ and contractors’ credentials.
Navigation
This topic focuses on low-level implementation details for building usable and accessible web-based user interfaces.
CMS sites must allow users to skip repetitive navigational links (i.e., skip navigation) when they use screen readers and have keyboard access. This allows users to jump directly into a site’s main content. Figure 4. Skip Navigation Example illustrates an example of skip navigation from the United States Department of Agriculture. Each heading along the bottom row of this figure, which appears near the top of this web page, is a link that users can select to jump directly to that category or function. For implementation details, follow https://www.hhs.gov/web/section-508/making-files-accessible/html-required/index.html for CSS and HTML implementations. More information about “Skip Navigation” Links can also be found at http://webaim.org/techniques/skipnav/.
Rationale:
Please refer to https://www.hhs.gov/web/policies-and-standards/index.html and http://www.access-board.gov/sec508/guide/1194.22.htm#(o) for additional details.
BR-UI-6: Provide a Home Page Link
CMS sites must provide a home page link in text format on every page associated with a specific website. HHS prescribes that the home page link must be placed at the top of the main (left) navigation panel. The use of “home” or “[Site] Home” as primary text is the standard. If graphics are used as a link to the home page, an accompanying text link must be present on the page. If the site has a unique logo or header, those elements should be linked to the home page as a supplement to the text link.
Rationale:
Please refer to https://www.hhs.gov/web/policies-and-standards/index.html for implementation details.
CMS sites must not use frames. According to HHS, frames are meta-documents that enable the display of multiple documents within a single browser window, but frames could lead to accessibility and navigation issues for screen reader users.
Rationale:
HHS discusses a set of exceptions for using frames. Please refer to https://www.hhs.gov/web/policies-and-standards/index.html for additional information.
To ensure accessible navigation, CMS websites must provide keyboard actions as alternatives to mouse or gesture events for interacting with the website.
Rationale:
A keyboard event handler should be provided that executes the same function as the mouse event handler, as shown in Table - Mouse Actions and Example Equivalent Keyboard Actions. Please refer to http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/SCR20 and http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/SCR2 for implementation details using JavaScript and HTML.
Consult Apple’s Safari Web Content Guide for mapping multi-touch gestures to equivalent mouse events or Windows User Experience Interaction Guidelines for mapping gestures to equivalent mouse and keyboard events.
Privacy and Information Security
This topic focuses on building web-based user interfaces that incorporate privacy protection and security measures.
BR-UI-9: Phishing and Redirection Prevention
Links must be provided to the CMS-recommended State Fraud and Abuse Contact Report and HHS’s Office of the Inspector General’s Report Fraud Form.
Rationale:
CMS websites must minimize phishing attacks, which often involve improper redirection and unnecessary exposure of personal email addresses on websites. Please refer to CWE-601: URL Redirection to Untrusted Site for implementation details to prevent redirecting users. Another way to ensure a site is credible is to use Go.USA.gov to create short yet trustworthy Uniform Resource Locators.
BR-UI-10: Cross-Site Request Forgery Prevention
CMS websites must use effective methods to protect against Cross-Site Request Forgery (CSRF).
OWASP suggests these methods for more effectively preventing CSRF attacks:
-
A challenge-response, such as Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHA), re-authentication through password, and one-time tokens are possible defenses against CSRF. As W3C discusses, CAPTCHA is not 508-compatible and could create inaccessibility. W3C suggests other approaches (http://www.w3.org/TR/turingtest/#solutions) such as logic puzzles or auditory CAPTCHA to replace traditional CAPTCHA.
-
Warn users that they should not allow their browsers to save usernames or passwords. Also, do not enable CMS websites to “remember” users’ login information.
-
Warn users that they should not use the same browser to access sensitive applications and to browse the Internet freely (tabbed browsing).
-
Advise users that the use of plugins such as No-Script makes POST based CSRF vulnerabilities difficult to exploit.
According to OWASP, the following four methods are neither appropriate nor effective for preventing CSRF:
-
Session identifiers, like cookies, are simply used by applications to associate requests with specific sessions. The session identifier does not verify that the user intended to submit the request.
-
POST requests are often considered to limit CSRF attacks because attackers cannot construct a malicious link, and therefore, a CSRF attack cannot be executed. Yet there are methods where an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in an attacker’s website with hidden values.
-
Multi-step transactions are not adequate to prevent CSRF. If an attacker can predict or deduce each step of the completed transaction, then CSRF is possible.
-
Rewriting the session ID in a URL might be a useful CSRF prevention technique because the attacker cannot guess the victim’s session ID; however, the user’s credentials could be exposed over the URL.
Rationale:
CSRF attacks make a target system perform a function (funds transfer, form submission, etc.) via the target’s browser without knowledge of the target user, at least until the unauthorized function has been committed.
CMS websites may allow anonymous access as follows:
The organization permits actions to be performed without identification and authentication only to the extent necessary to accomplish CMS mission/business objectives. (ARS AC-14)
Otherwise, a CMS website must authenticate all users according to the policies established in the CMS ARS , which may include HSPD-12 compliance.
Rationale:
Authentication is the process of verifying that individuals are who they claim to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.
To prevent authentication attacks, observe and practice the following:
-
Implement authentication management practices identified in the CMS ARS Security Control IA-5(1) for password complexity and other factors
-
Utilize multi-factor authentication
-
Serve the initial login page via secured connection, e.g., secure socket layer (SSL)
-
Implement account lock-out to prevent brute-force attack
CMS websites must implement secure sessions.
Rationale:
Session management is a process by which a server remembers how to react to subsequent requests throughout a transaction. A session identifier maintains sessions on the server that can be passed backward and forward between the client and server when transmitting and receiving requests.
To enhance session management, observe and practice the following server-side defenses:
-
Session ID names used by the most common web application development frameworks can be easily identified for potential exploit. This includes PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET). Instead of using one of these, change the default session ID name of the web development framework to a generic name, such as “id.”
-
Consider installing a web policy agent that a web server can call to make policy decisions when a client requests access to a protected resource.
-
Use a session ID length of at least 128 bits (16 bytes) to prevent brute force attacks.
-
Session ID must be unpredictable (random enough) to prevent guessing attacks.
-
Use latest web development frameworks, such as J2EE, ASP .NET, PHP, for session management instead of building a home-made one from scratch, because these frameworks are used worldwide on multiple Web environments and have been tested by the web application security and development communities.
-
The most common session ID generation mechanism in use today is a strict one in which web applications will only accept session ID values that have been previously generated by the web application.
-
Set expiration timeouts for every session. Insufficient session expiration by the web application increases the chance for attackers to reuse a valid session ID and hijack the associated session. The session expiration timeout values must be set according to the purpose and nature of the web application and also balance security and usability so that users can comfortably complete the operations within the web application.
-
Web applications must provide a visible and easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu. The button should be reachable from every web application resource and page, to ensure that users can manually close the session at any time.
To further enhance session management protection, observe and practice the following client-side defenses:
-
Enforce login timeout on the login page and notify users that the maximum amount of time to log in has passed. This allows the renewal of the session ID for authentication and avoids scenarios where a previously used (or manually set) session ID is reused.
-
When users choose to close a web browser tab or window, close the current session for users before closing the web browser. This helps users close a session if they forget to click a logout button.
CMS websites must secure Protected Health Information.
Mitigations may include limiting what PHI elements are displayed to a user, or displaying only partial elements such as a partial Social Security Number (SSN), a partial email address, or partial telephone number.
Rationale:
The HIPAA Privacy Rule, prescribes that 18 elements are considered PHI (http://privacyrule andresearch.nih.gov/pr_08.asp#8a). These elements must be removed or generalized.
For a summary, please consult Summary of the HIPAA Privacy Rule.
CMS websites must meet the CMS ARS standard for user identifiers. If permitted, use easy to remember and recognizable user identification for identifying and tracking user identity.
Rationale:
When users have the freedom to choose data that are meaningful to them as user identification, that identifying information can be recalled more easily. Consider allowing users to use their first and last initials. Another possibility is to allow email addresses as user identification.
For additional details, please refer to Chapter 4 of HHS’s HIPAA Security Series, Security Standards: Technical Safeguards.
CMS websites must validate all user input at a minimum on the server side, although validating at both the client and server side is recommended because it allows better system performance and quicker response for the users.
Rationale:
According to the CWE:
Use an allowlist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a denylist). However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules.
For a counter example of improper user input validation and ways to mitigate this issue, please refer to CWE-20: Improper Input Validation and OWASP Improper_Data_Validation.
For information about other related issues, software errors, or attacks, please refer to CWE/SANS TOP 25 Most Dangerous Software Errors.
BR-UI-17: (Deprecated after TRA 2017R1): Information Security
A website should disclose only the minimum sensitive information necessary for authorized users to perform the tasks required, as described in the following examples:
-
When users log in, they should not see their entire Social Security Number unless absolutely necessary. This will prevent shoulder surfing, for example.
-
When users check a claim, they should not see more information about that claim than is necessary for the task at hand.
-
When users file a change of address, they do not need to see their prior address in its entirety.
Layout, Style, and Appearance
These rules focus on building web-based user interfaces following best practices to ensure compatibility with the broad range of browsers and devices that users may employ.
BR-UI-19: Color Contrast Ratio
CMS sites must ensure a color contrast ratio of 4.5:1.
To calculate the color contrast ratio, follow this equation:
-
(L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance of the lighter of the colors and L2 is the relative luminance of the darker of the colors.
-
Alternatively, consult http://webaim.org/resources/contrastchecker/ for an online version for performing color contrast check. Also, refer to http://www.w3.org/TR/ 2010/NOTE-WCAG20-TECHS-20101014/working-examples/G183/link-contrast.html and http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-visual-presentation for specific implementation details.
Rationale:
According to the W3C, a contrast ratio of 3:1 is the minimum level for standard text and vision; however, to satisfy Section 508 accessibility, a 4.5:1 is necessary to account for those who have low visual acuity, congenital or acquired color deficiencies, or the loss of contrast sensitivity due to aging.
BR-UI-20: (Deprecated after TRA 2017R1): Standard Colors
BR-UI-21: (Deprecated after TRA 2017R1): Deprecated Elements
BR-UI-22: (Deprecated after TRA 2017R1): CSS Version
BR-UI-23: (Deprecated after TRA 2017R1): HTML Version
BR-UI-24: (Deprecated after TRA 2017R1): JavaScript
BR-UI-25: Scripts Compatibility
CMS websites must be ARIA compliant and allow web browsers to operate without JavaScript.
Rationale:
Not all web browsers support JavaScript, and some users may have their browsers configured to block or disable JavaScript. CMS websites must provide users of such browsers with content and services, or directions to obtain content and services offered by the website.
BR-UI-26: (Deprecated after TRA 2017R1): Logo
Other Guiding Principles
This topic presents other subjects not directly addressed in the foregoing UX business rules.
Mobile Interfaces
Mobile Web applications must not store PII local to the mobile device in a persistent manner (although temporary, in-memory use is permissible). This applies, at a minimum, to cached contents, cookies, and HTML5 local data stores.