Access to Web content is implemented in a secure and accountable manner.]]>This section covers information on Web browsers, plug-ins and active content including the development and implementation of appropriate use policies. ]]>The requirements in this section apply equally to the Web accessed via the Internet as well as websites accessed on an agency intranet.]]>An example of open source software that manages allow lists for client-side JavaScript controls is available at:
]]>If agencies allow system users to access the Web they will need to define the extent of Web access that is granted. This can be achieved through the development, and awareness raising amongst system users, of a Web usage policy.]]>Agencies MUST develop and implement a policy governing appropriate Web usage.]]>Web proxies provide valuable information in determining if malicious code is performing regular interactions over Web traffic. Web proxies also provide usable information if system users are violating agency Web usage policies.]]>Agencies SHOULD use a Web proxy for all Web browsing activities.]]>An agency’s Web proxy SHOULD authenticate system users and provide logging that includes at least the following details about websites accessed:
address (uniform resource locator);
time/date;
system user;
internal IP address; and
external IP address.
]]>Agencies SHOULD NOT permit downloading of executable files from external websites unless there is a demonstrable and approved business requirement.]]>Web browsers can be configured to allow the automatic launching of downloaded files. This can occur with or without the system user’s knowledge thus making the workstation vulnerable to attack.]]>Agencies SHOULD disable the automatic launching of files downloaded from external websites.]]>As TLS encrypted Web traffic travelling over HTTPS connections can deliver content without any filtering, agencies can reduce this security risk by using TLS inspection so that the Web traffic can be filtered.]]>An alternative of using an allow list for HTTPS websites can allow websites that have a low security risk of delivering malicious code and have a high privacy requirement like Web banking, to continue to have end-to-end encryption.]]>It is however, important to note that there are many recorded cases of websites generally considered to be a low security risk that have been compromised.]]>Agencies permitting TLS through their gateways SHOULD implement:
a solution that decrypts and inspects the TLS traffic as per content filtering requirements; or
an allow list specifying the addresses (uniform resource locators) to which encrypted connections are permitted, with all other addresses blocked.
]]>Encrypted TLS traffic may contain personal information. Agencies should seek legal advice on whether inspecting such traffic is in breach of the Privacy Act or other legislation. User policies should incorporate an explanation of the security drivers and acknowledgement from users on the policy contents and requirements. Refer to Chapter 9 – Personnel Security and Chapter 15 – Email Security.]]>Agencies SHOULD seek legal advice regarding the inspection of encrypted TLS traffic by their gateways.]]>Defining an allow list of permitted websites and blocking all unlisted websites limits one of the most common data delivery and exfiltration techniques used by malicious code. However, if agency personnel have a legitimate requirement to access a numerous and rapidly changing list of websites, agencies will need to consider the practicality and costs of such an implementation. In such cases deny listing is a limited but none-the-less effective measure.]]>Agencies SHOULD implement allow listing for all HTTP traffic being communicated through their gateways.]]>Agencies using an allow list on their gateways to specify the external addresses, to which encrypted connections are permitted, SHOULD specify allow list addresses by domain name or IP address.]]>If agencies do not allow list websites they SHOULD deny list websites to prevent access to known malicious websites.]]>Agencies deny listing websites SHOULD update the deny list on a frequent basis to ensure that it remains effective.]]>Software that runs on agency systems SHOULD be controlled by the agency. Active content delivered though websites should be constrained so that it cannot arbitrarily access system users’ files or deliver malicious code. Unfortunately the implementations of Web browsers regularly contain flaws that permit such activity.]]>Agencies SHOULD block client-side active content, such as Java and ActiveX, which are assessed as having a limited business impact.]]>Agencies SHOULD:
use client-side controls that allow JavaScript on a per website basis; and
add JavaScript functions used only for malicious purposes to the agency Web content filter or IDS/IPS.
]]>Using a Web proxy provides agencies with an opportunity to filter potentially harmful information to system users and their workstations.]]>Agencies SHOULD use the Web proxy to filter content that is potentially harmful to system users and their workstations.]]>Some websites require the use of a userID and password as the authentication mechanism. The management of passwords on these websites is often insecure and there are numerous examples of compromises where tens of thousands, and sometimes millions of passwords are compromised in a single incident. Where the same password is used on multiple websites, an incident can potentially compromise the user’s account on every website using that password. It is important to treat these websites as insecure and manage passwords appropriately.]]>Users MUST NOT use agency userID and login passwords as credentials for external websites.]]>Users SHOULD NOT store web site authentication credentials (userID and password) on workstations, remote access devices (such as laptops) or BYO devices.]]>Users SHOULD NOT use the same password for multiple websites.]]>