opexxx

list_of_security_controls

Jan 31st, 2022
111
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 109.36 KB | None | 0 0
  1. A CISO is appointed to provide cyber security leadership and guidance for their organisation.
  2. The CISO oversees their organisation’s cyber security program and ensures their organisation’s compliance with cyber security policy, standards, regulations and legislation.
  3. The CISO regularly reviews and updates their organisation’s cyber security program to ensure its relevance in addressing cyber threats and harnessing business and cyber security opportunities.
  4. The CISO implements cyber security measurement metrics and key performance indicators for their organisation.
  5. The CISO coordinates cyber security and business alignment through a cyber security steering committee or advisory board, comprising of key cyber security and business executives, which meets formally and on a regular basis.
  6. The CISO coordinates security risk management activities between cyber security and business teams.
  7. The CISO reports directly to their organisation’s senior executive and/or Board on cyber security matters.
  8. The CISO is fully aware of all cyber security incidents within their organisation.
  9. The CISO oversees their organisation’s response to cyber security incidents.
  10. The CISO contributes to the development and maintenance of business continuity and disaster recovery plans for their organisation to ensure that business-critical services are supported appropriately in the event of a disaster.
  11. The CISO develops and maintains a cyber security communications strategy for their organisation.
  12. The CISO oversees cyber supply chain risk management activities for their organisation.
  13. The CISO receives and manages a dedicated cyber security budget for their organisation.
  14. The CISO oversees the management of cyber security personnel within their organisation.
  15. The CISO oversees the development and operation of their organisation’s cyber security awareness training program.
  16. Each system has a designated system owner.
  17. System owners register each system with its authorising officer.
  18. System owners determine the type, value and security objectives for each system based on an assessment of the impact if it were to be compromised.
  19. System owners select security controls for each system and tailor them to achieve desired security objectives.
  20. System owners implement security controls for each system and its operating environment.
  21. System owners ensure security controls for each system and its operating environment are assessed to determine if they have been implemented correctly and are operating as intended.
  22. System owners obtain authorisation to operate each system from its authorising officer based on the acceptance of the security risks associated with its operation.
  23. System owners monitor each system, and associated cyber threats, security risks and security controls, on an ongoing basis.
  24. System owners report the security status of each system to its authorising officer at least annually.
  25. An intrusion detection and prevention policy is developed and implemented.
  26. A trusted insider program is developed and implemented.
  27. Legal advice is sought regarding the development and implementation of a trusted insider program.
  28. Cyber security personnel have access to sufficient data sources and tools to ensure that systems can be monitored for key indicators of compromise.
  29. "A cyber security incident register is maintained that covers the following:
  30. • the date the cyber security incident occurred
  31. • the date the cyber security incident was discovered
  32. • a description of the cyber security incident
  33. • any actions taken in response to the cyber security incident
  34. • to whom the cyber security incident was reported."
  35. When a data spill occurs, data owners are advised and access to the data is restricted.
  36. "When malicious code is detected, the following steps are taken to handle the infection:
  37. • the infected systems are isolated
  38. • all previously connected media used in the period leading up to the infection are scanned for signs of infection and isolated if necessary
  39. • antivirus software is used to remove the infection from infected systems and media
  40. • if the infection cannot be reliably removed, systems are restored from a known good backup or rebuilt."
  41. Legal advice is sought before allowing intrusion activity to continue on a system for the purpose of collecting further data or evidence.
  42. System owners are consulted before allowing intrusion activity to continue on a system for the purpose of collecting further data or evidence.
  43. Planning and coordination of intrusion remediation activities are conducted on a separate system to that which has been compromised.
  44. To the extent possible, all intrusion remediation activities are conducted in a coordinated manner during the same planned outage.
  45. Following intrusion remediation activities, full network traffic is captured for at least seven days and analysed to determine whether the adversary has been successfully removed from the system.
  46. "The integrity of evidence gathered during an investigation is maintained by investigators:
  47. • recording all of their actions
  48. • creating checksums for all evidence
  49. • copying evidence onto media for archiving
  50. • maintaining a proper chain of custody."
  51. Cyber security incidents are reported to an organisation’s CISO, or one of their delegates, as soon as possible after they occur or are discovered.
  52. Service providers report cyber security incidents to their customer’s CISO, or one of their delegates, as soon as possible after they occur or are discovered.
  53. Service providers and their customers maintain 24x7 contact details for each other, including additional out-of-band contact details for when normal communication channels fail, in order to report cyber security incidents.
  54. Cyber security incidents are reported to the ACSC.
  55. Components and services relevant to the security of systems are identified and understood.
  56. Before obtaining components and services relevant to the security of systems, a review of suppliers and service providers (including their country of origin) is performed to assess the potential increase to systems’ security risk profile, including by identifying those that are high risk.
  57. Suppliers and service providers identified as high risk are not used.
  58. Components and services relevant to the security of systems are chosen from suppliers and service providers that have made a commitment to secure-by-design practices.
  59. Components and services relevant to the security of systems are chosen from suppliers and service providers that have a strong track record of transparency and maintaining the security of their own systems, services and cyber supply chains.
  60. A shared responsibility model is created, documented and shared between suppliers, service providers and their customers in order to articulate the security responsibilities of each party.
  61. An outsourced cloud services register is maintained and regularly audited.
  62. "An outsourced cloud services register contains the following for each outsourced cloud service:
  63. • cloud service provider’s name
  64. • cloud service’s name
  65. • purpose for using the cloud service
  66. • sensitivity or classification of data involved
  67. • due date for the next security assessment of the cloud service
  68. • point of contact for users of the cloud service
  69. • point of contact for the cloud service provider."
  70. Cloud service providers and their cloud services undergo a security assessment by an IRAP assessor at least every 24 months.
  71. Only community or private clouds are used for outsourced SECRET and TOP SECRET cloud services.
  72. Service providers provide an appropriate level of protection for any data entrusted to them or their services.
  73. Security requirements associated with the confidentiality, integrity and availability of data entrusted to a service provider are documented in contractual arrangements.
  74. The right to audit security controls associated with the protection of data and services is specified in contractual arrangements.
  75. Types of data and its ownership is documented in contractual arrangements.
  76. The regions or availability zones where data will be processed, stored and communicated is documented in contractual arrangements.
  77. Access to all logs relating to an organisation’s data and services are specified in contractual arrangements.
  78. Data entrusted to a service provider is stored in a portable manner that allows organisations to perform backups, service migration or service decommissioning without any loss of data.
  79. A minimum notification period of one month for the cessation of any services by a service provider is documented in contractual arrangements.
  80. An organisation’s systems and data are not accessed or administered by a service provider unless a contractual arrangement exists between the organisation and the service provider to do so.
  81. If an organisation’s systems or data are accessed or administered by a service provider in an unauthorised manner, organisations are immediately notified.
  82. A cyber security strategy is developed and implemented for the organisation.
  83. Organisational-level security documentation is approved by the Chief Information Security Officer while system-specific security documentation is approved by the system’s authorising officer.
  84. Security documentation is reviewed at least annually and includes a ‘current as at [date]’ or equivalent statement.
  85. Security documentation, including notification of subsequent changes, is communicated to all stakeholders.
  86. Systems have a system security plan that includes a description of the system and an annex that covers both applicable security controls from this document and any additional security controls that have been identified.
  87. "Systems have an incident response plan that covers the following:
  88. • guidelines on what constitutes a cyber security incident
  89. • the types of cyber security incidents likely to be encountered and the expected response to each type
  90. • how to report cyber security incidents, internally to the organisation and externally to relevant authorities
  91. • other parties which need to be informed in the event of a cyber security incident
  92. • the authority, or authorities, responsible for investigating and responding to cyber security incidents
  93. • the criteria by which an investigation of a cyber security incident would be requested from a law enforcement agency, the Australian Cyber Security Centre or other relevant authority
  94. • the steps necessary to ensure the integrity of evidence relating to a cyber security incident
  95. • system contingency measures or a reference to such details if they are located in a separate document."
  96. "Systems have a continuous monitoring plan that includes:
  97. • conducting vulnerability scans for systems at least monthly
  98. • conducting vulnerability assessments or penetration tests for systems at least annually
  99. • analysing identified security vulnerabilities to determine their potential impact
  100. • using a risk-based approach to prioritise the implementation of mitigations based on effectiveness and cost."
  101. "At the conclusion of a security assessment for a system, a security assessment report is produced by the assessor and covers:
  102. • the scope of the security assessment
  103. • the system’s strengths and weaknesses
  104. • security risks associated with the operation of the system
  105. • the effectiveness of the implementation of security controls
  106. • any recommended remediation actions."
  107. At the conclusion of a security assessment for a system, a plan of action and milestones is produced by the system owner.
  108. Systems are secured in facilities that meet the requirements for a security zone suitable for their sensitivity or classification.
  109. Servers, network devices and cryptographic equipment are secured in server rooms or communications rooms that meet the requirements for a security zone suitable for their sensitivity or classification.
  110. Servers, network devices and cryptographic equipment are secured in security containers or secure rooms suitable for their sensitivity or classification taking into account the combination of security zones they reside in.
  111. Server rooms, communications rooms, security containers and secure rooms are not left in unsecured states.
  112. Keys or equivalent access mechanisms to server rooms, communications rooms, security containers and secure rooms are appropriately controlled.
  113. Physical security controls are implemented to protect network devices in public areas from physical damage or unauthorised access.
  114. An authorised RF and IR device register is maintained and regularly audited for SECRET and TOP SECRET areas.
  115. Unauthorised RF and IR devices are not brought into SECRET and TOP SECRET areas.
  116. Security measures are used to detect and respond to unauthorised RF devices in SECRET and TOP SECRET areas.
  117. Unauthorised people are prevented from observing systems, in particular workstation displays and keyboards, within facilities.
  118. ICT equipment and media are secured when not in use.
  119. "Cyber security awareness training is undertaken annually by all personnel and covers:
  120. • the purpose of the cyber security awareness training
  121. • security appointments and contacts within the organisation
  122. • authorised use of systems and their resources
  123. • protection of systems and their resources
  124. • reporting of cyber security incidents and suspected compromises of systems and their resources."
  125. Tailored privileged user training is undertaken annually by all privileged users.
  126. Personnel are advised of what suspicious contact via online services is and how to report it.
  127. Personnel are advised to not post work information to unauthorised online services and to report cases where such information is posted.
  128. Personnel are advised to maintain separate work and personal accounts for online services.
  129. Personnel are advised of security risks associated with posting personal information to online services and are encouraged to use any available privacy settings to restrict who can view such information.
  130. Personnel are advised not to send or receive files via unauthorised online services.
  131. Access requirements for a system and its resources are documented in its system security plan.
  132. Personnel undergo appropriate employment screening, and where necessary hold an appropriate security clearance, before being granted access to a system and its resources.
  133. Personnel receive any necessary briefings before being granted access to a system and its resources.
  134. Personnel granted access to a system and its resources are uniquely identifiable.
  135. The use of shared user accounts is strictly controlled, and personnel using such accounts are uniquely identifiable.
  136. Personnel who are contractors are identified as such.
  137. Where a system processes, stores or communicates AUSTEO, AGAO or REL data, personnel who are foreign nationals are identified as such, including by their specific nationality.
  138. Requests for unprivileged access to systems, applications and data repositories are validated when first requested.
  139. Use of unprivileged access is logged.
  140. Unprivileged access event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.
  141. Foreign nationals, including seconded foreign nationals, do not have access to systems that process, store or communicate AUSTEO or REL data unless effective security controls are in place to ensure such data is not accessible to them.
  142. Foreign nationals, excluding seconded foreign nationals, do not have access to systems that process, store or communicate AGAO data unless effective security controls are in place to ensure such data is not accessible to them.
  143. Requests for privileged access to systems and applications are validated when first requested.
  144. Requests for privileged access to data repositories are validated when first requested.
  145. Privileged access to systems and applications is limited to only what is required for users and services to undertake their duties.
  146. Privileged user accounts are prevented from accessing the internet, email and web services.
  147. Privileged service accounts are prevented from accessing the internet, email and web services.
  148. Just-in-time administration is used for administering systems and applications.
  149. Privileged users are assigned a dedicated privileged account to be used solely for tasks requiring privileged access.
  150. Use of privileged access is logged.
  151. Changes to privileged accounts and groups are logged.
  152. Privileged access event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.
  153. Privileged account and group change event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.
  154. Foreign nationals, including seconded foreign nationals, do not have privileged access to systems that process, store or communicate AUSTEO or REL data.
  155. Foreign nationals, excluding seconded foreign nationals, do not have privileged access to systems that process, store or communicate AGAO data.
  156. Access to systems, applications and data repositories is removed or suspended on the same day personnel no longer have a legitimate requirement for access.
  157. Access to systems, applications and data repositories is removed or suspended as soon as practicable when personnel are detected undertaking malicious activities.
  158. Unprivileged access to systems and applications is automatically disabled after 45 days of inactivity.
  159. Privileged access to systems and applications is automatically disabled after 45 days of inactivity.
  160. Access to data repositories is automatically disabled after 45 days of inactivity.
  161. Privileged access to systems and applications is automatically disabled after 12 months unless revalidated.
  162. Privileged access to data repositories is automatically disabled after 12 months unless revalidated.
  163. "A secure record is maintained for the life of each system covering:
  164. • all personnel authorised to access the system, and their user identification
  165. • who provided authorisation for access
  166. • when access was granted
  167. • the level of access that was granted
  168. • when access, and the level of access, was last reviewed
  169. • when the level of access was changed, and to what extent (if applicable)
  170. • when access was withdrawn (if applicable)."
  171. When personnel are granted temporary access to a system, effective security controls are put in place to restrict their access to only data required for them to undertake their duties.
  172. Temporary access is not granted to systems that process, store or communicate caveated or sensitive compartmented information.
  173. A method of emergency access to systems is documented and tested at least once when initially implemented and each time fundamental information technology infrastructure changes occur.
  174. Break glass accounts are only used when normal authentication processes cannot be used.
  175. Break glass accounts are only used for specific authorised activities.
  176. Use of break glass accounts is logged.
  177. Break glass event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.
  178. Break glass account credentials are changed by the account custodian after they are accessed by any other party.
  179. Break glass accounts are tested after credentials are changed.
  180. Systems processing, storing or communicating AUSTEO or AGAO data remain at all times under the control of an Australian national working for or on behalf of the Australian Government.
  181. AUSTEO and AGAO data can only be accessed from systems under the sole control of the Australian Government that are located within facilities authorised by the Australian Government.
  182. Cabling infrastructure is installed in accordance with relevant Australian Standards, as directed by the Australian Communications and Media Authority.
  183. Fibre-optic cables are used for cabling infrastructure instead of copper cables.
  184. A cable register is maintained and regularly audited.
  185. "A cable register contains the following for each cable:
  186. • cable identifier
  187. • cable colour
  188. • sensitivity/classification
  189. • source
  190. • destination
  191. • location
  192. • seal numbers (if applicable)."
  193. Floor plan diagrams are maintained and regularly audited.
  194. "Floor plan diagrams contain the following:
  195. • cable paths (including ingress and egress points between floors)
  196. • cable reticulation system and conduit paths
  197. • floor concentration boxes
  198. • wall outlet boxes
  199. • network cabinets."
  200. Cable labelling processes, and supporting cable labelling procedures, are developed and implemented.
  201. Cables are labelled at each end with sufficient source and destination details to enable the physical identification and inspection of the cable.
  202. Building management cables are labelled with their purpose in black writing on a yellow background, with a minimum size of 2.5 cm x 1 cm, and attached at five-metre intervals.
  203. Cables for foreign systems installed in Australian facilities are labelled at inspection points.
  204. OFFICIAL and PROTECTED cables are coloured neither salmon pink nor red.
  205. SECRET cables colours are coloured salmon pink.
  206. TOP SECRET cables colours are coloured red.
  207. SECRET and TOP SECRET cables with non-conformant cable colouring are both banded with the appropriate colour and labelled at inspection points.
  208. Cables are inspectable at a minimum of five-metre intervals.
  209. Cables in TOP SECRET areas are fully inspectable for their entire length.
  210. SECRET and TOP SECRET systems belong exclusively to their own cable groups.
  211. Cables only carry a single cable group, unless each cable group belongs to a different subunit.
  212. Cable groups sharing a common cable reticulation system have a dividing partition or a visible gap between the cable groups.
  213. In shared facilities, cables are run in an enclosed cable reticulation system.
  214. In shared facilities, conduits or the front covers of ducts, cable trays in floors and ceilings, and associated fittings are clear plastic.
  215. In shared facilities, uniquely identifiable SCEC endorsed tamper-evident seals are used to seal all removable covers on TOP SECRET cable reticulation systems.
  216. In shared facilities, a visible smear of conduit glue is used to seal all plastic conduit joints and TOP SECRET conduits connected by threaded lock nuts.
  217. Labels for TOP SECRET conduits are a minimum size of 2.5 cm x 1 cm, attached at five-metre intervals and marked as ‘TS RUN’.
  218. Cables from cable trays to wall outlet boxes are run in flexible or plastic conduit.
  219. In shared facilities, TOP SECRET cables are not run in party walls.
  220. Where wall penetrations exit a TOP SECRET area into a lower classified area, TOP SECRET cables are encased in conduit with all gaps between the TOP SECRET conduit and the wall filled with an appropriate sealing compound.
  221. Wall outlet boxes have connectors on opposite sides of the wall outlet box if the cable group contains cables belonging to different systems.
  222. Different cables groups do not share a wall outlet box.
  223. Wall outlet boxes denote the systems, cable identifiers and wall outlet box identifier.
  224. OFFICIAL and PROTECTED wall outlet boxes are coloured neither salmon pink nor red.
  225. SECRET wall outlet boxes are coloured salmon pink.
  226. TOP SECRET wall outlet boxes are coloured red.
  227. Wall outlet box covers are clear plastic.
  228. If TOP SECRET fibre-optic fly leads exceeding five metres in length are used to connect wall outlet boxes to ICT equipment, they are run in a protective and easily inspected pathway that is clearly labelled at the ICT equipment end with the wall outlet box’s identifier.
  229. Cable reticulation systems leading into cabinets are terminated as close as possible to the cabinet.
  230. In TOP SECRET areas, cable reticulation systems leading into cabinets in server rooms or communications rooms are terminated as close as possible to the cabinet.
  231. In TOP SECRET areas, cable reticulation systems leading into cabinets not in server rooms or communications rooms are terminated at the boundary of the cabinet.
  232. Cables are terminated in individual cabinets; or for small systems, one cabinet with a division plate to delineate cable groups.
  233. TOP SECRET cables are terminated in an individual TOP SECRET cabinet.
  234. Different cable groups do not terminate on the same patch panel.
  235. There is a visible gap between TOP SECRET cabinets and cabinets of lower classifications.
  236. TOP SECRET and non-TOP SECRET patch panels are physically separated by installing them in separate cabinets.
  237. "Where spatial constraints demand patch panels of lower classifications than TOP SECRET be located in the same cabinet as a TOP SECRET patch panel:
  238. • a physical barrier in the cabinet is provided to separate patch panels
  239. • only personnel holding a Positive Vetting security clearance have access to the cabinet
  240. • approval from the TOP SECRET system’s authorising officer is obtained prior to installation."
  241. When penetrating a TOP SECRET audio secure room, the Australian Security Intelligence Organisation is consulted and all directions provided are complied with.
  242. A power distribution board with a feed from an Uninterruptible Power Supply is used to power all TOP SECRET ICT equipment.
  243. System owners deploying OFFICIAL or PROTECTED systems with Radio Frequency transmitters that will be co-located with SECRET or TOP SECRET systems contact the ACSC for an emanation security threat assessment and implement any additional installation criteria derived from the threat assessment.
  244. System owners deploying SECRET or TOP SECRET systems with Radio Frequency transmitters inside or co-located with their facility contact the ACSC for an emanation security threat assessment and implement any additional installation criteria derived from the threat assessment.
  245. System owners deploying SECRET or TOP SECRET systems in shared facilities contact the ACSC for an emanation security threat assessment and implement any additional installation criteria derived from the threat assessment.
  246. System owners deploying systems or military platforms overseas contact the ACSC for an emanation security threat assessment and implement any additional installation criteria derived from the threat assessment.
  247. An emanation security threat assessment is sought as early as possible in a project’s life cycle as emanation security controls can have significant cost implications.
  248. ICT equipment meets industry and government standards relating to electromagnetic interference/electromagnetic compatibility.
  249. A telephone system usage policy is developed and implemented.
  250. Personnel are advised of the permitted sensitivity or classification of information that can be discussed over both internal and external telephone systems.
  251. Personnel are advised of security risks posed by non-secure telephone systems in areas where sensitive or classified conversations can occur.
  252. When using cryptographic equipment to permit different levels of conversation for different kinds of connections, telephone systems give a visual indication of what kind of connection has been made.
  253. Telephone systems used for sensitive or classified conversations encrypt all traffic that passes over external systems.
  254. Cordless telephone systems are not used for sensitive or classified conversations.
  255. Speakerphones are not used on telephone systems in TOP SECRET areas unless the telephone system is located in an audio secure room, the room is audio secure during conversations and only personnel involved in conversations are present in the room.
  256. Off-hook audio protection features are used on telephone systems in areas where background conversations may exceed the sensitivity or classification that the telephone system is authorised for communicating.
  257. In SECRET and TOP SECRET areas, push-to-talk handsets or push-to-talk headsets are used to meet any off-hook audio protection requirements.
  258. Video conferencing and IP telephony infrastructure is hardened.
  259. Where a requirement exists to implement a firewall in a gateway, and video conferencing or IP telephony traffic passes through the gateway, a video-aware and/or voice-aware firewall is used.
  260. Video conferencing and IP telephony calls are established using a secure session initiation protocol.
  261. Video conferencing and IP telephony calls are conducted using a secure real-time transport protocol.
  262. An encrypted and non-replayable two-way authentication scheme is used for call authentication and authorisation.
  263. Authentication and authorisation is used for all actions on a video conferencing network, including call setup and changing settings.
  264. Authentication and authorisation is used for all actions on an IP telephony network, including registering a new IP phone, changing phone users, changing settings and accessing voicemail.
  265. "IP telephony is configured such that:
  266. • IP phones authenticate themselves to the call controller upon registration
  267. • auto-registration is disabled and only authorised devices are allowed to access the network
  268. • unauthorised devices are blocked by default
  269. • all unused and prohibited functionality is disabled."
  270. Individual logins are implemented for IP phones used for SECRET or TOP SECRET conversations.
  271. Video conferencing and IP telephony traffic is separated physically or logically from other data traffic.
  272. Workstations are not connected to video conferencing units or IP phones unless the workstation or the device uses Virtual Local Area Networks or similar mechanisms to maintain separation between video conferencing, IP telephony and other data traffic.
  273. IP phones used in public areas do not have the ability to access data networks, voicemail and directory services.
  274. Microphones (including headsets and USB handsets) and webcams are not used with non-SECRET workstations in SECRET areas.
  275. Microphones (including headsets and USB handsets) and webcams are not used with non-TOP SECRET workstations in TOP SECRET areas.
  276. "A denial of service response plan is developed and implemented for video conferencing and IP telephony services that includes:
  277. • how to identify signs of a denial-of-service attack
  278. • how to identify the source of a denial-of-service attack
  279. • how capabilities can be maintained during a denial-of-service attack
  280. • what actions can be taken to respond to a denial-of-service attack."
  281. A fax machine and MFD usage policy is developed and implemented.
  282. Separate fax machines or MFDs are used for sending sensitive or classified fax messages and all other fax messages.
  283. When sending fax messages, the fax message is encrypted to an appropriate level to be communicated over unsecured telecommunications infrastructure.
  284. The sender of a fax message makes arrangements for the receiver to collect the fax message as soon as possible after it is sent and for the receiver to notify the sender if the fax message does not arrive in an agreed amount of time.
  285. Security controls for MFDs connected to a network are of a similar strength to those for other devices on the network.
  286. A direct connection from an MFD to a digital telephone system is not enabled unless the digital telephone system is authorised to operate at the same sensitivity or classification as the network to which the MFD is connected.
  287. MFDs connected to networks are not used to copy documents above the sensitivity or classification of the connected network.
  288. Fax machines and MFDs are located in areas where their use can be observed.
  289. A mobile device management policy is developed and implemented.
  290. A Mobile Device Management solution is used to ensure mobile device management policy is applied to all mobile devices.
  291. Mobile devices do not process, store or communicate SECRET or TOP SECRET data until approved for use by the ACSC.
  292. Legal advice is sought prior to allowing privately-owned mobile devices to access systems or data.
  293. Personnel accessing OFFICIAL and PROTECTED systems or data using a privately-owned mobile device use an ACSC approved platform, a security configuration in accordance with ACSC guidance and have enforced separation of work data from any personal data.
  294. Privately-owned mobile devices do not access SECRET and TOP SECRET systems or data.
  295. Personnel accessing systems or data using an organisation-owned mobile device use an ACSC approved platform with a security configuration in accordance with ACSC guidance.
  296. Mobile devices encrypt their internal storage and any removable media.
  297. Mobile devices encrypt all sensitive or classified data communicated over public network infrastructure.
  298. Mobile devices are configured to remain undiscoverable to other Bluetooth devices except during Bluetooth pairing.
  299. Bluetooth pairing is performed using Secure Connections, preferably with Numeric Comparison if supported.
  300. Bluetooth pairing is performed in a manner such that connections are only made between intended Bluetooth devices.
  301. Bluetooth pairings are removed when there is no longer a requirement for their use.
  302. Bluetooth functionality is not enabled on SECRET and TOP SECRET mobile devices.
  303. Mobile devices prevent personnel from installing or uninstalling non-approved applications once provisioned.
  304. Mobile devices prevent personnel from disabling or modifying security functionality once provisioned.
  305. Security updates are applied to mobile devices as soon as they become available.
  306. Mobile devices access the internet via a VPN connection to an organisation’s internet gateway rather than via a direct connection to the internet.
  307. When accessing an organisation’s network via a VPN connection, split tunnelling is disabled.
  308. A mobile device usage policy is developed and implemented.
  309. Personnel are advised of the sensitivity or classification permitted for voice and data communications when using mobile devices.
  310. Paging, Multimedia Message Service, Short Message Service and messaging apps are not used to communicate sensitive or classified data.
  311. Sensitive or classified data is not viewed or communicated in public locations unless care is taken to reduce the chance of the screen of a mobile device being observed.
  312. Privacy filters are applied to the screens of SECRET and TOP SECRET mobile devices.
  313. Sensitive or classified phone calls are not conducted in public locations unless care is taken to reduce the chance of conversations being overheard.
  314. Mobile devices are kept under continual direct supervision when being actively used.
  315. Mobile devices are carried or stored in a secured state when not being actively used.
  316. If unable to carry or store mobile devices in a secured state, they are physically transferred in a security briefcase or an approved multi-use satchel, pouch or transit bag.
  317. Mobile device emergency sanitisation processes, and supporting mobile device emergency sanitisation procedures, are developed and implemented.
  318. If a cryptographic zeroise or sanitise function is provided for cryptographic keys on a SECRET or TOP SECRET mobile device, the function is used as part of mobile device emergency sanitisation processes and procedures.
  319. Personnel are advised of privacy and security risks when travelling overseas with mobile devices.
  320. "If travelling overseas with mobile devices to high or extreme risk countries, personnel are:
  321. • issued with newly provisioned accounts, mobile devices and removable media from a pool of dedicated travel devices which are used solely for work-related activities
  322. • advised on how to apply and inspect tamper seals to key areas of mobile devices
  323. • advised to avoid taking any personal mobile devices, especially if rooted or jailbroken."
  324. "Before travelling overseas with mobile devices, personnel take the following actions:
  325. • record all details of the mobile devices being taken, such as product types, serial numbers and International Mobile Equipment Identity numbers
  326. • update all operating systems and applications
  327. • remove all non-essential accounts, applications and data
  328. • apply security configuration settings, such as lock screens
  329. • configure remote locate and wipe functionality
  330. • enable encryption, including for any removable media
  331. • backup all important data and configuration settings."
  332. "Personnel take the following precautions when travelling overseas with mobile devices:
  333. • never leaving mobile devices or removable media unattended for any period of time, including by placing them in checked-in luggage or leaving them in hotel safes
  334. • never storing credentials with mobile devices that they grant access to, such as in laptop bags
  335. • never lending mobile devices or removable media to untrusted people, even if briefly
  336. • never allowing untrusted people to connect their mobile devices or removable media, including for charging
  337. • never using designated charging stations, wall outlet charging ports or chargers supplied by untrusted people
  338. • avoiding connecting mobile devices to open or untrusted Wi-Fi networks
  339. • using a VPN connection to encrypt all mobile device communications
  340. • using encrypted messaging apps for communications instead of using foreign telecommunication networks
  341. • disabling any communications capabilities of mobile devices when not in use, such as cellular data, wireless, Bluetooth and Near Field Communication
  342. • avoiding reuse of removable media once used with other parties’ systems or mobile devices
  343. • ensuring any removable media used for data transfers are thoroughly checked for malicious code beforehand
  344. • never using any gifted mobile devices, especially removable media, when travelling or upon returning from travelling."
  345. "Personnel report the potential compromise of mobile devices, removable media or credentials to their organisation as soon as possible, especially if they:
  346. • provide credentials to foreign government officials
  347. • decrypt mobile devices for foreign government officials
  348. • have mobile devices taken out of sight by foreign government officials
  349. • have mobile devices or removable media stolen that are later returned
  350. • lose mobile devices or removable media that are later found
  351. • observe unusual behaviour of mobile devices."
  352. "Upon returning from travelling overseas with mobile devices, personnel take the following actions:
  353. • sanitise and reset mobile devices, including all removable media
  354. • decommission any physical credentials that left their possession during their travel
  355. • report if significant doubt exists as to the integrity of any mobile devices or removable media."
  356. "If returning from travelling overseas with mobile devices to high or extreme risk countries, personnel take the following additional actions:
  357. • reset user credentials used with mobile devices, including those used for remote access to their organisation’s systems
  358. • monitor accounts for any indicators of compromise, such as failed logon attempts."
  359. If procuring an evaluated product, a product that has completed a PP-based evaluation is selected in preference to one that has completed an EAL-based evaluation.
  360. Evaluated products are delivered in a manner consistent with any delivery procedures defined in associated evaluation documentation.
  361. When procuring high assurance ICT equipment, the ACSC is contacted for any equipment-specific delivery procedures.
  362. Evaluated products are installed, configured, administered and operated in accordance with vendor guidance and evaluation documentation.
  363. High assurance ICT equipment is installed, configured, administered and operated in accordance with guidance produced by the ACSC.
  364. High assurance ICT equipment is always operated in an evaluated configuration.
  365. An ICT equipment management policy is developed and implemented.
  366. An ICT equipment register is maintained and regularly audited.
  367. ICT equipment, with the exception of high assurance ICT equipment, is labelled with protective markings reflecting its sensitivity or classification.
  368. The Australian Cyber Security Centre (ACSC)’s approval is sought before applying labels to external surfaces of high assurance ICT equipment.
  369. ICT equipment is classified based on the highest sensitivity or classification of data that it is approved for processing, storing or communicating.
  370. ICT equipment is handled in a manner suitable for its sensitivity or classification.
  371. The ACSC’s approval is sought before undertaking any maintenance or repairs to high assurance ICT equipment.
  372. Maintenance and repairs of ICT equipment is carried out on site by an appropriately cleared technician.
  373. If an uncleared technician is used to undertake maintenance or repairs of ICT equipment, the ICT equipment and associated media is sanitised before maintenance or repair work is undertaken.
  374. "If an uncleared technician is used to undertake maintenance or repairs of ICT equipment, the technician is escorted by someone who:
  375. • is appropriately cleared and briefed
  376. • takes due care to ensure that data is not disclosed
  377. • takes all responsible measures to ensure the integrity of the ICT equipment
  378. • has the authority to direct the technician
  379. • is sufficiently familiar with the ICT equipment to understand the work being performed."
  380. ICT equipment maintained or repaired off site is done so in accordance with the handling requirements for the sensitivity or classification of the ICT equipment.
  381. Following maintenance or repair activities for ICT equipment, the ICT equipment is inspected to confirm it retains its approved software configuration and that no unauthorised modifications have taken place.
  382. ICT equipment sanitisation processes, and supporting ICT equipment sanitisation procedures, are developed and implemented.
  383. ICT equipment disposal processes, and supporting ICT equipment disposal procedures, are developed and implemented.
  384. Labels and markings indicating the owner, sensitivity, classification or any other marking that can associate ICT equipment with its prior use are removed prior to its disposal.
  385. When disposing of ICT equipment containing media, the ICT equipment is sanitised by sanitising the media within the ICT equipment, removing the media from the ICT equipment or destroying the ICT equipment in its entirety.
  386. When disposing of high assurance ICT equipment, it is destroyed prior to its disposal.
  387. When disposing of ICT equipment that has been designed or modified to meet emanation security standards, the ACSC is contacted for requirements relating to its disposal.
  388. Following sanitisation, destruction or declassification, a formal administrative decision is made to release ICT equipment, or its waste, into the public domain.
  389. ICT equipment, including associated media, that is located overseas and has processed, stored or communicated AUSTEO or AGAO data, is sanitised in situ.
  390. ICT equipment, including associated media, that is located overseas and has processed, stored or communicated AUSTEO or AGAO data that cannot be sanitised in situ, is returned to Australia for destruction.
  391. At least three pages of random text with no blank areas are printed on each colour printer cartridge or MFD print drum.
  392. MFD print drums and image transfer rollers are inspected and destroyed if there is remnant toner which cannot be removed or a print is visible on the image transfer roller.
  393. Printer and MFD platens are inspected and destroyed if any text or images are retained on the platen.
  394. Printers and MFDs are checked to ensure no pages are trapped in the paper path due to a paper jam.
  395. When unable to sanitise printer cartridges or MFD print drums, they are destroyed as per electrostatic memory devices.
  396. Printer ribbons in printers and MFDs are removed and destroyed.
  397. Televisions and computer monitors with minor burn-in or image persistence are sanitised by displaying a solid white image on the screen for an extended period of time.
  398. Televisions and computer monitors that cannot be sanitised are destroyed.
  399. "Memory in network devices is sanitised using the following processes, in order of preference:
  400. • following device-specific guidance provided in evaluation documentation
  401. • following vendor sanitisation guidance
  402. • loading a dummy configuration file, performing a factory reset and then reinstalling firmware."
  403. The paper tray of the fax machine is removed, and a fax message with a minimum length of four pages is transmitted, before the paper tray is re-installed to allow a fax summary page to be printed.
  404. Fax machines are checked to ensure no pages are trapped in the paper path due to a paper jam.
  405. A media management policy is developed and implemented.
  406. A removable media usage policy is developed and implemented.
  407. A removable media register is maintained and regularly audited.
  408. Media, with the exception of internally mounted fixed media within ICT equipment, is labelled with protective markings reflecting its sensitivity or classification.
  409. Media is classified to the highest sensitivity or classification of data it stores, unless the media has been classified to a higher sensitivity or classification.
  410. Media is only used with systems that are authorised to process, store or communicate its sensitivity or classification.
  411. Any media connected to a system with a higher sensitivity or classification than the media is reclassified to the higher sensitivity or classification, unless the media is read-only or the system has a mechanism through which read-only access can be ensured.
  412. Before reclassifying media to a lower sensitivity or classification, it is either sanitised or the data it stores is reclassified in consultation with data owners, and a formal administrative decision is made to reclassify the media.
  413. Media is handled in a manner suitable for its sensitivity or classification.
  414. All data stored on media is encrypted.
  415. Media is sanitised before it is used for the first time.
  416. Media is sanitised before it is reused in a different security domain.
  417. When transferring data manually between two systems belonging to different security domains, write-once media is used unless the destination system has a mechanism through which read-only access can be ensured.
  418. When transferring data manually between two systems belonging to different security domains, rewritable media is sanitised after each data transfer.
  419. Media sanitisation processes, and supporting media sanitisation procedures, are developed and implemented.
  420. Volatile media is sanitised by removing its power for at least 10 minutes.
  421. SECRET and TOP SECRET volatile media is sanitised by overwriting it at least once in its entirety with a random pattern followed by a read back for verification.
  422. Following sanitisation, TOP SECRET volatile media retains its classification if it stored static data for an extended period of time, or had data repeatedly stored on or written to the same memory location for an extended period of time.
  423. Non-volatile magnetic media is sanitised by overwriting it at least once (or three times if pre-2001 or under 15 GB) in its entirety with a random pattern followed by a read back for verification.
  424. The host-protected area and device configuration overlay table are reset prior to the sanitisation of non-volatile magnetic hard drives.
  425. The ATA secure erase command is used, in addition to block overwriting software, to ensure the growth defects table of non-volatile magnetic hard drives is overwritten.
  426. Following sanitisation, SECRET and TOP SECRET non-volatile magnetic media retains its classification.
  427. Non-volatile EPROM media is sanitised by applying three times the manufacturer’s specified ultraviolet erasure time and then overwriting it at least once in its entirety with a random pattern followed by a read back for verification.
  428. Non-volatile EEPROM media is sanitised by overwriting it at least once in its entirety with a random pattern followed by a read back for verification.
  429. Following sanitisation, SECRET and TOP SECRET non-volatile EPROM and EEPROM media retains its classification.
  430. Non-volatile flash memory media is sanitised by overwriting it at least twice in its entirety with a random pattern followed by a read back for verification.
  431. Following sanitisation, SECRET and TOP SECRET non-volatile flash memory media retains its classification.
  432. Faulty or damaged media that cannot be successfully sanitised is destroyed prior to its disposal.
  433. Media destruction processes, and supporting media destruction procedures, are developed and implemented.
  434. "The following media types are destroyed prior to their disposal:
  435. • microfiche and microfilm
  436. • optical discs
  437. • programmable read-only memory
  438. • read-only memory
  439. • other types of media that cannot be sanitised."
  440. SCEC or ASIO approved equipment is used when destroying media.
  441. If using degaussers to destroy media, degaussers evaluated by the United States’ National Security Agency are used.
  442. Equipment that is capable of reducing microform to a fine powder, with resultant particles not showing more than five consecutive characters per particle upon microscopic inspection, is used to destroy microfiche and microfilm.
  443. Electrostatic memory devices are destroyed using either furnace/incinerator, hammer mill, disintegrator or grinder/sander destruction methods.
  444. Magnetic floppy disks are destroyed using either furnace/incinerator, hammer mill, disintegrator, cutting or degausser destruction methods.
  445. Magnetic hard disks are destroyed using either furnace/incinerator, hammer mill, disintegrator, grinder/sander or degausser destruction methods.
  446. Magnetic tapes are destroyed using either furnace/incinerator, hammer mill, disintegrator, cutting or degausser destruction methods.
  447. Optical disks are destroyed using either furnace/incinerator, hammer mill, disintegrator, grinder/sander or cutting destruction methods.
  448. Semiconductor memory is destroyed using either furnace/incinerator, hammer mill or disintegrator destruction methods.
  449. Media destroyed using either a hammer mill, disintegrator, grinder/sander or cutting destruction method result in media waste particles no larger than 9 mm.
  450. The resulting media waste particles from the destruction of SECRET media is stored and handled as OFFICIAL if less than or equal to 3 mm, PROTECTED if greater than 3 mm and less than or equal to 6 mm, or SECRET if greater than 6 mm and less than or equal to 9 mm.
  451. The resulting media waste particles from the destruction of TOP SECRET media is stored and handled as OFFICIAL if less than or equal to 3 mm, or SECRET if greater than 3 mm and less than or equal to 9 mm.
  452. Magnetic media is destroyed using a degausser with a suitable magnetic field strength and magnetic orientation.
  453. Any product-specific directions provided by degausser manufacturers are followed.
  454. Following destruction of magnetic media using a degausser, it is physically damaged (such as by deforming the internal platters of hard drives) prior to its disposal.
  455. The destruction of media is performed under the supervision of at least one person cleared to its sensitivity or classification.
  456. Personnel supervising the destruction of media supervise its handling to the point of destruction and ensure that the destruction is completed successfully.
  457. The destruction of media storing accountable material is performed under the supervision of at least two personnel cleared to its sensitivity or classification.
  458. Personnel supervising the destruction of media storing accountable material supervise its handling to the point of destruction, ensure that the destruction is completed successfully and sign a destruction certificate afterwards.
  459. When outsourcing the destruction of media to an external destruction service, a National Association for Information Destruction AAA certified destruction service with endorsements, as specified in ASIO’s PSC-167, is used.
  460. The destruction of media storing accountable material is not outsourced.
  461. Media disposal processes, and supporting media disposal procedures, are developed and implemented.
  462. Labels and markings indicating the owner, sensitivity, classification or any other marking that can associate media with its prior use are removed prior to its disposal.
  463. Following sanitisation, destruction or declassification, a formal administrative decision is made to release media, or its waste, into the public domain.
  464. SOEs are used for workstations and servers.
  465. SOEs provided by third parties are scanned for malicious content and configurations before being used.
  466. SOEs are reviewed and updated at least annually.
  467. The latest release, or the previous release, of operating systems are used for workstations, servers and network devices.
  468. When developing a Microsoft Windows SOE, the 64-bit version of the operating system is used.
  469. ACSC and vendor guidance is implemented to assist in hardening the configuration of operating systems.
  470. Default operating system accounts are disabled, renamed or have their passphrase changed.
  471. Unneeded operating system accounts, software, components, services and functionality are disabled or removed.
  472. Automatic execution features for removable media are disabled.
  473. Internet Explorer 11 is disabled or removed.
  474. .NET Framework 3.5 (includes .NET 2.0 and 3.0) is disabled or removed.
  475. Unprivileged users are prevented from bypassing, disabling or modifying security functionality of operating systems.
  476. "Unprivileged users are prevented from running script execution engines in Microsoft Windows, including:
  477. • Windows Script Host (cscript.exe and wscript.exe)
  478. • PowerShell (powershell.exe, powershell_ise.exe and pwsh.exe)
  479. • Command Prompt (cmd.exe)
  480. • Windows Management Instrumentation (wmic.exe)
  481. • Microsoft Hypertext Markup Language (HTML) Application Host (mshta.exe)."
  482. Local administrator accounts are disabled; alternatively, passphrases that are random and unique for each device’s local administrator account are used.
  483. Unique domain accounts with local administrative privileges, but without domain administrative privileges, are used for workstation and server management.
  484. Users do not have the ability to install unapproved software.
  485. Users do not have the ability to uninstall or disable approved software.
  486. Application control is implemented on workstations.
  487. Application control is implemented on internet-facing servers.
  488. Application control is implemented on non-internet-facing servers.
  489. Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.
  490. Application control restricts the execution of drivers to an organisation-approved set.
  491. Application control is implemented using cryptographic hash rules, publisher certificate rules or path rules.
  492. Application control rulesets are validated on an annual or more frequent basis.
  493. When implementing application control using publisher certificate rules, both publisher names and product names are used.
  494. When implementing application control using path rules, file system permissions are configured to prevent unauthorised modification of folder and file permissions, folder contents (including adding new files) and individual files that are approved to execute.
  495. Microsoft’s ‘recommended block rules’ are implemented.
  496. Microsoft’s ‘recommended driver block rules’ are implemented.
  497. All users (with the exception of privileged users when performing specific administrative activities) cannot disable, bypass or be exempted from application control.
  498. Allowed and blocked executions on workstations are logged.
  499. Allowed and blocked executions on internet-facing servers are logged.
  500. Allowed and blocked executions on non-internet facing servers are logged.
  501. Application control event logs including the name of the file, the date/time stamp and the username of the user associated with the event.
  502. Application control event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.
  503. Microsoft’s exploit protection functionality is implemented on workstations and servers.
  504. Windows PowerShell 2.0 is disabled or removed.
  505. PowerShell is configured to use Constrained Language Mode.
  506. PowerShell is configured to use module logging, script block logging and transcription functionality.
  507. PowerShell script block logs are protected by Protected Event Logging functionality.
  508. Blocked PowerShell script executions are logged.
  509. PowerShell event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.
  510. A HIPS is implemented on workstations.
  511. A HIPS is implemented on high value servers such as authentication servers, Domain Name System servers, web servers, file servers and email servers.
  512. A software firewall is implemented on workstations and servers to limit both inbound and outbound network connections.
  513. "Antivirus software is implemented on workstations and servers and configured with:
  514. • signature-based detection enabled and set to a high level
  515. • heuristic-based detection enabled and set to a high level
  516. • ransomware protection measures enabled
  517. • detection signatures checked for currency and updated on at least a daily basis
  518. • automatic and regular scanning configured for all fixed disks and removable media."
  519. Antivirus software has reputation rating functionality enabled.
  520. Unauthorised removable media and devices are prevented from being connected to workstations and servers via the use of device access control software or by disabling external communication interfaces in operating systems.
  521. External communication interfaces that allow DMA are disabled.
  522. Removable media is prevented from being written to via the use of device access control software if there is no business requirement for its use.
  523. Applications are chosen from vendors that have made a commitment to secure development and maintenance practices.
  524. The latest releases of office productivity suites, web browsers and their extensions, email clients, PDF software, and security products are used when present within SOEs.
  525. The latest releases of web server software, server applications that store important data, and other internet-accessible server applications are used when present within SOEs.
  526. Web browsers do not process Java from the internet.
  527. Web browsers do not process web advertisements from the internet.
  528. Internet Explorer 11 does not process content from the internet.
  529. Microsoft Office is blocked from creating child processes.
  530. Microsoft Office is blocked from creating executable content.
  531. Microsoft Office is blocked from injecting code into other processes.
  532. Microsoft Office is configured to prevent activation of Object Linking and Embedding packages.
  533. PDF software is blocked from creating child processes.
  534. ACSC or vendor hardening guidance for web browsers, Microsoft Office and PDF software is implemented.
  535. Any unrequired functionality in web browsers, Microsoft Office and PDF software is disabled.
  536. The use of web browser, Microsoft Office and PDF software add-ons is restricted to organisation approved add-ons.
  537. If supported, Microsoft’s Attack Surface Reduction rules are implemented.
  538. Web browsers, Microsoft Office and PDF software security settings cannot be changed by users.
  539. Microsoft Office macros are disabled for users that do not have a demonstrated business requirement.
  540. Microsoft Office macros in files originating from the internet are blocked.
  541. Microsoft Office macro antivirus scanning is enabled.
  542. Microsoft Office macros are blocked from making Win32 API calls.
  543. Only Microsoft Office macros running from within a sandboxed environment, a Trusted Location or that are digitally signed by a trusted publisher are allowed to execute.
  544. Only privileged users responsible for validating that Microsoft Office macros are free of malicious code can write to and modify content within Trusted Locations.
  545. Microsoft Office macros digitally signed by an untrusted publisher cannot be enabled via the Message Bar or Backstage View.
  546. Microsoft Office’s list of trusted publishers is validated on an annual or more frequent basis.
  547. Microsoft Office macro security settings cannot be changed by users.
  548. Allowed and blocked Microsoft Office macro executions are logged.
  549. Microsoft Office macro event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.
  550. Users are authenticated before they are granted access to a system and its resources.
  551. Multi-factor authentication is used to authenticate unprivileged users of systems.
  552. Multi-factor authentication is used to authenticate privileged users of systems.
  553. Multi-factor authentication is used by an organisation’s users if they authenticate to their organisation’s internet-facing services.
  554. Multi-factor authentication is used by an organisation’s users if they authenticate to third-party internet-facing services that process, store or communicate their organisation's sensitive data.
  555. Multi-factor authentication (where available) is used by an organisation’s users if they authenticate to third-party internet-facing services that process, store or communicate their organisation's non-sensitive data.
  556. Multi-factor authentication is enabled by default for non-organisational users (but users can choose to opt out) if they authenticate to an organisation’s internet-facing services.
  557. Multi-factor authentication is used to authenticate users accessing important data repositories.
  558. Multi-factor authentication uses either: something users have and something users know, or something users have that is unlocked by something users know or are.
  559. Multi-factor authentication is verifier impersonation resistant.
  560. Passwords used for multi-factor authentication are a minimum of 6 characters, unless more stringent requirements apply.
  561. Passwords used for multi-factor authentication on SECRET systems are a minimum of 8 characters.
  562. Passwords used for multi-factor authentication on TOP SECRET systems are a minimum of 10 characters.
  563. When multi-factor authentication is implemented, none of the authentication factors on their own can be used for single-factor authentication to another system.
  564. Successful and unsuccessful multi-factor authentications are logged.
  565. Multi-factor authentication event logs are centrally stored and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.
  566. When systems cannot support multi-factor authentication, single-factor authentication using passphrases is implemented instead.
  567. Passphrases used for single-factor authentication are at least 4 random words with a total minimum length of 14 characters, unless more stringent requirements apply.
  568. Passphrases used for single-factor authentication on SECRET systems are at least 5 random words with a total minimum length of 17 characters.
  569. Passphrases used for single-factor authentication on TOP SECRET systems are at least 6 random words with a total minimum length of 20 characters.
  570. "Passphrases used for single-factor authentication:
  571. • are not constructed from song lyrics, movies, literature or any other publicly available material
  572. • do not form a real sentence in a natural language
  573. • are not a list of categorised words."
  574. Passphrases used for single-factor authentication cannot be used to authenticate to multiple different systems.
  575. Passwords/passphrases set or reset on users’ behalf are randomly generated.
  576. Users provide sufficient evidence to verify their identity when collecting a password/passphrase for their account.
  577. Passwords/passphrases are provided to users via a secure communications channel or, if not possible, split into parts with part being provided to the user and part provided to the user’s supervisor.
  578. Users that do not set their own initial password/passphrase are required to change it on first use.
  579. Service accounts are created as group Managed Service Accounts.
  580. Accounts are locked out after a maximum of five failed logon attempts.
  581. Repeated account lockouts are investigated before reauthorising access.
  582. Users provide sufficient evidence to verify their identity when requesting an account unlock.
  583. Authentication methods susceptible to replay attacks are disabled.
  584. LAN Manager and NT LAN Manager authentication methods are disabled.
  585. Privileged accounts are members of the Protected Users security group.
  586. Credentials for local administrator accounts and service accounts are unique, unpredictable and managed.
  587. Credentials are stored separately from systems to which they grant access.
  588. Credentials are obscured as they are entered into systems.
  589. Stored passwords/passphrases are protected by ensuring they are hashed, salted and stretched.
  590. Windows Defender Credential Guard and Windows Defender Remote Credential Guard are enabled.
  591. "Passwords/passphrases are changed if:
  592. • they are directly compromised
  593. • they are suspected of being compromised
  594. • they appear in online data breach databases
  595. • they are discovered stored in the clear on a network
  596. • they are discovered being transferred in the clear across a network
  597. • membership of a shared account changes
  598. • they have not been changed in the past 12 months."
  599. Outside of business hours, and after an appropriate period of inactivity, user sessions are terminated and workstations are rebooted.
  600. "Systems are configured with a session or screen lock that:
  601. • activates after a maximum of 15 minutes of user inactivity, or if manually activated by the user
  602. • conceals all session content on the screen
  603. • ensures that the screen does not enter a power saving state before the session or screen lock is activated
  604. • requires the user to reauthenticate to unlock the system
  605. • denies users the ability to disable the session or screen locking mechanism."
  606. Systems have a logon banner that requires users to acknowledge and accept their security responsibilities before access is granted.
  607. Legal advice is sought on the exact wording of logon banners.
  608. When using a software-based isolation mechanism to share a physical server’s hardware, the isolation mechanism is from a vendor that uses secure coding practices and, when security vulnerabilities have been identified, develops and distributes patches in a timely manner.
  609. When using a software-based isolation mechanism to share a physical server’s hardware, the configuration of the isolation mechanism is hardened by removing unneeded functionality and restricting access to the administrative interface used to manage the isolation mechanism.
  610. When using a software-based isolation mechanism to share a physical server’s hardware, the underlying operating system running on the server is hardened.
  611. When using a software-based isolation mechanism to share a physical server’s hardware, patches are applied to the isolation mechanism and underlying operating system in a timely manner.
  612. When using a software-based isolation mechanism to share a physical server’s hardware, integrity and log monitoring are performed for the isolation mechanism and underlying operating system in a timely manner.
  613. When using a software-based isolation mechanism to share a physical server’s hardware for SECRET or TOP SECRET workloads, the physical server and all computing environments running on the physical server are of the same classification and within the same security domain.
  614. System administration processes, and supporting system administration procedures, are developed and implemented.
  615. Privileged users use separate privileged and unprivileged operating environments.
  616. Privileged operating environments are not virtualised within unprivileged operating environments.
  617. Unprivileged accounts cannot logon to privileged operating environments.
  618. Privileged accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments.
  619. Dedicated administrator workstations used for privileged tasks are prevented from communicating to assets not related to administrative activities.
  620. All administrative infrastructure including, but not limited to, administrator workstations and jump servers are hardened.
  621. Administrator workstations are placed into a separate network zone to user workstations.
  622. Management traffic is only allowed to originate from network zones that are used to administer systems and applications.
  623. Administrative activities are conducted through jump servers.
  624. Jump servers are prevented from communicating to assets and sending and receiving traffic not related to administrative activities.
  625. Patch management processes, and supporting patch management procedures, are developed and implemented.
  626. Software registers are maintained and regularly audited for workstations, servers, mobile devices, network devices and all other ICT equipment.
  627. Software registers contain versions and patch histories of applications, drivers, operating systems and firmware.
  628. Patches, updates or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.
  629. Patches, updates or vendor mitigations for security vulnerabilities in office productivity suites, web browsers and their extensions, email clients, PDF software, and security products are applied within two weeks of release.
  630. Patches, updates or vendor mitigations for security vulnerabilities in office productivity suites, web browsers and their extensions, email clients, PDF software, and security products are applied within 48 hours if an exploit exists.
  631. Patches, updates or vendor mitigations for security vulnerabilities in other applications are applied within one month.
  632. Patches, updates or vendor mitigations for security vulnerabilities in operating systems of internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.
  633. Patches, updates or vendor mitigations for security vulnerabilities in operating systems of workstations, servers and network devices are applied within two weeks of release.
  634. Patches, updates or vendor mitigations for security vulnerabilities in operating systems of workstations, servers and network devices are applied within 48 hours if an exploit exists.
  635. Patches, updates or vendor mitigations for security vulnerabilities in drivers and firmware are applied within two weeks of release, or within 48 hours if an exploit exists.
  636. High assurance ICT equipment is only patched or updated when approved by the ACSC using methods and timeframes prescribed by the ACSC.
  637. A centralised and managed approach is used to patch or update applications and drivers.
  638. An approach for patching or updating applications and drivers that ensures the integrity and authenticity of patches or updates, as well as the processes used to apply them, is used.
  639. An automated mechanism is used to confirm and record that deployed application and driver patches or updates have been installed, applied successfully and remain in place.
  640. A centralised and managed approach is used to patch or update operating systems and firmware.
  641. An approach for patching or updating operating systems and firmware that ensures the integrity and authenticity of patches or updates, as well as the processes used to apply them, is used.
  642. An automated mechanism is used to confirm and record that deployed operating system and firmware patches or updates have been installed, applied successfully and remain in place.
  643. A vulnerability scanner is used at least daily to identify missing patches or updates for security vulnerabilities in internet-facing services.
  644. A vulnerability scanner is used at least weekly to identify missing patches or updates for security vulnerabilities in office productivity suites, web browsers and their extensions, email clients, PDF software, and security products.
  645. A vulnerability scanner is used at least fortnightly to identify missing patches or updates for security vulnerabilities in other applications.
  646. A vulnerability scanner is used at least daily to identify missing patches for security vulnerabilities in operating systems of internet-facing services.
  647. A vulnerability scanner is used at least weekly to identify missing patches for security vulnerabilities in operating systems of workstations, servers and network devices.
  648. A vulnerability scanner is used at least weekly to identify missing patches for security vulnerabilities in drivers and firmware.
  649. Internet-facing services, office productivity suites, web browsers and their extensions, email clients, PDF software, Adobe Flash Player, and security products that are no longer supported by vendors are removed.
  650. Applications that are no longer supported by vendors are removed.
  651. Operating systems that are no longer supported by vendors are replaced.
  652. "Change management processes, and supporting change management procedures, are developed and implemented covering:
  653. • identification and documentation of requests for change
  654. • approval required for changes to be made
  655. • assessment of potential security impacts
  656. • notification of any planned disruptions or outages
  657. • implementation and testing of approved changes
  658. • the maintenance of system and security documentation."
  659. A digital preservation policy is developed and implemented.
  660. Data backup processes, and supporting data backup procedures, are developed and implemented.
  661. Data restoration processes, and supporting data restoration procedures, are developed and implemented.
  662. Backups of important data, software and configuration settings are performed and retained in a coordinated and resilient manner in accordance with business continuity requirements.
  663. Unprivileged accounts, and privileged accounts (excluding backup administrators) cannot access other account’s backups.
  664. Unprivileged accounts, and privileged accounts (excluding backup administrators) can’t access their own account’s backups.
  665. Unprivileged accounts, and privileged accounts (excluding backup administrators), are prevented from modifying or deleting backups.
  666. Backup administrators (excluding backup break glass accounts), are prevented from modifying or deleting backups.
  667. Restoration of systems, software and important data from backups is tested in a coordinated manner as part of disaster recovery exercises.
  668. An event logging policy is developed and implemented.
  669. A centralised logging facility is implemented and systems are configured to save event logs to the centralised logging facility as soon as possible after each event occurs.
  670. An accurate time source is established and used consistently across systems and network devices to assist with the correlation of events.
  671. For any system requiring authentication, logon, failed logon and logoff events are logged.
  672. "The following events are logged for operating systems:
  673. • access to important data and processes
  674. • application crashes and any error messages
  675. • attempts to use special privileges
  676. • changes to accounts
  677. • changes to security policy
  678. • changes to system configurations
  679. • Domain Name System and Hypertext Transfer Protocol requests
  680. • failed attempts to access data and system resources
  681. • service failures and restarts
  682. • system startup and shutdown
  683. • transfer of data to and from external media
  684. • user or group management
  685. • use of special privileges."
  686. "The following events are logged for web applications:
  687. • attempted access that is denied
  688. • crashes and any error messages
  689. • search queries initiated by users."
  690. "The following events are logged for databases:
  691. • access to particularly important data
  692. • addition of new users, especially privileged users
  693. • any query containing comments
  694. • any query containing multiple embedded queries
  695. • any query or database alerts or failures
  696. • attempts to elevate privileges
  697. • attempted access that is successful or unsuccessful
  698. • changes to the database structure
  699. • changes to user roles or database permissions
  700. • database administrator actions
  701. • database logons and logoffs
  702. • modifications to data
  703. • use of executable commands."
  704. For each event logged, the date and time of the event, the relevant user or process, the event description, and the ICT equipment involved are recorded.
  705. Event logs are protected from unauthorised access, modification and deletion.
  706. Event logs are retained for a minimum of 7 years in accordance with the NAA’s Administrative Functions Disposal Authority Express Version 2 publication.
  707. Domain Name System and proxy logs are retained for at least 18 months.
  708. Event log auditing processes, and supporting event log auditing procedures, are developed and implemented covering the scope and schedule of audits, what constitutes a violation of security policy, and actions to be taken when violations are detected, including reporting requirements.
  709. Events are correlated across event logs to prioritise audits and focus investigations.
  710. Development, testing and production environments are segregated.
  711. Development and modification of software only takes place in development environments.
  712. Data in production environments is not used in testing or development environments unless the testing or development environments are secured to the same level as the production environments.
  713. Unauthorised access to the authoritative source for software is prevented.
  714. Threat modelling and other secure design techniques are used to ensure that threats to software and mitigations to those threats are identified and accounted for.
  715. A software bill of materials is produced and made available to consumers of software.
  716. Platform-specific secure programming practices are used when developing software, including using the lowest privilege needed to achieve a task, checking return values of all system calls, validating all inputs and encrypting all communications.
  717. Software is tested for security vulnerabilities by software developers, as well as an independent party, before it is used in a production environment.
  718. A vulnerability disclosure program is implemented to assist with the secure development and maintenance of products and services.
  719. A ‘security.txt’ file is hosted for all internet-facing organisational domains to assist in the responsible disclosure of security vulnerabilities in organisations’ products and services.
  720. Robust web application frameworks are used to aid in the development of secure web applications.
  721. All web application content is offered exclusively using HTTPS.
  722. Validation and/or sanitisation is performed on all input handled by a web application.
  723. Output encoding is performed on all output produced by a web application.
  724. Web applications implement Content-Security-Policy, HSTS and X-Frame-Options response headers.
  725. The OWASP Application Security Verification Standard is followed when developing web applications.
  726. Hard disks of database servers are encrypted using full disk encryption.
  727. Database servers and web servers are functionally separated, physically or virtually.
  728. Data communicated between database servers and web applications is encrypted.
  729. Database servers that require network connectivity are placed on a different network segment to an organisation’s workstations.
  730. Network access controls are implemented to restrict database server communications to strictly defined network resources such as web servers, application servers and storage area networks.
  731. If only local access to a database is required, networking functionality of database management system (DBMS) software is disabled or directed to listen solely to the localhost interface.
  732. Test and development environments do not use the same database servers as production environments.
  733. All temporary installation files and logs are removed after DBMS software has been installed.
  734. DBMS software is configured according to vendor guidance.
  735. DBMS software features, stored procedures, accounts and databases that are not required are disabled or removed.
  736. DBMS software is configured to run as a separate account with the minimum privileges needed to perform its functions.
  737. The account under which DBMS software runs has limited access to non-essential areas of the database server’s file system.
  738. The ability of DBMS software to read local files from a server is disabled.
  739. Default database administrator accounts are disabled, renamed or have their passphrases changed.
  740. Database administrators have unique and identifiable accounts.
  741. Database administrator accounts are not shared across different databases.
  742. Database administrator accounts are used exclusively for administrative activities, with standard database accounts used for general purpose interactions with databases.
  743. Database administrator access is restricted to defined roles rather than accounts with default administrative permissions, or all permissions.
  744. A database register is maintained and regularly audited.
  745. File-based access controls are applied to database files.
  746. Passphrases stored in databases are hashed with a uniquely salted Australian Signals Directorate Approved Cryptographic Algorithm.
  747. Databases and their contents are classified based on the sensitivity or classification of data that they contain.
  748. Database users’ ability to access, insert, modify and remove content in databases is restricted based on their work duties.
  749. The need-to-know principle is enforced for database contents through the application of minimum privileges, database views and database roles.
  750. Where concerns exist that the sum, or aggregation, of separate pieces of data from within databases could lead to a database user determining more sensitive or classified data, database views in combination with database user access roles are implemented.
  751. Data in production databases is not used in testing or development databases unless the testing or development environments are secured to the same level as the production environment.
  752. All queries to databases from web applications are filtered for legitimate content and correct syntax.
  753. Parameterised queries or stored procedures are used for database interaction instead of dynamically generated queries.
  754. Web applications are designed to provide as little error information as possible to users about database schemas.
  755. An email usage policy is developed and implemented.
  756. Access to non-approved webmail services is blocked.
  757. Protective markings are applied to emails and reflect the highest sensitivity or classification of the subject, body and attachments.
  758. Protective marking tools do not automatically insert protective markings into emails.
  759. Protective marking tools do not allow users to select protective markings that a system has not been authorised to process, store or communicate.
  760. Protective marking tools do not allow users replying to or forwarding an email to select a protective marking that is lower than previously used for the email.
  761. Email servers are configured to block, log and report emails with inappropriate protective markings.
  762. The intended recipients of any blocked inbound emails, and the sender of any blocked outbound emails, are notified.
  763. Emails containing Australian Eyes Only, Australian Government Access Only or Releasable To data are only sent to named recipients and not to groups or distribution lists unless the nationality of all members of the distribution lists can be confirmed.
  764. Email is routed through a centralised email gateway.
  765. When users send email from outside their network, an authenticated and encrypted channel is configured to allow email to be routed via a centralised email gateway.
  766. Where backup or alternative email gateways are in place, they are maintained at the same standard as the primary email gateway.
  767. Email servers only relay emails destined for or originating from their domains.
  768. Opportunistic TLS encryption is enabled on email servers that make incoming or outgoing email connections over public network infrastructure.
  769. MTA-STS is enabled to prevent the transfer of unencrypted emails between complying servers.
  770. SPF is used to specify authorised email services (or lack thereof) for all domains.
  771. A hard fail SPF record is used when specifying email servers.
  772. SPF is used to verify the authenticity of incoming emails.
  773. Incoming emails that fail SPF checks are blocked or marked in a manner that is visible to the recipients.
  774. DKIM signing is enabled on emails originating from an organisation’s domains.
  775. DKIM signatures on received emails are verified.
  776. Email distribution list software used by external senders is configured such that it does not break the validity of the sender’s DKIM signature.
  777. DMARC records are configured for all domains such that emails are rejected if they fail SPF or DKIM checks.
  778. Email content filtering controls are implemented for email bodies and attachments.
  779. Emails arriving via an external connection where the source address uses an internal domain name are blocked at the email gateway.
  780. Notification of undeliverable, bounced or blocked emails are only sent to senders that can be verified via SPF or other trusted means.
  781. Network documentation includes a high-level network diagram showing all connections into the network; a logical network diagram showing all network devices, critical servers and services; and the configuration of all network devices.
  782. Network documentation is updated as network configuration changes are made and includes a ‘current as at [date]’ or equivalent statement.
  783. Network documentation provided to a third party, or published in public tender documentation, only contains details necessary for other parties to undertake contractual services.
  784. Networks are divided into multiple functional network zones according to the sensitivity or criticality of data or services.
  785. Organisation networks are segregated from service provider networks.
  786. VLANs are not used to separate network traffic between organisations’ networks and public network infrastructure.
  787. VLANs are not used to separate network traffic between networks belonging to different security domains.
  788. Network devices managing VLANs terminate VLANs belonging to different security domains on separate physical network interfaces.
  789. Network devices managing VLANs belonging to different security domains do not share VLAN trunks.
  790. Network devices managing VLANs are administered from the most trusted security domain.
  791. IPv6 functionality is disabled in dual-stack network devices and ICT equipment unless it is being used.
  792. IPv6 capable network security devices are used on IPv6 and dual-stack networks.
  793. Unless explicitly required, IPv6 tunnelling is disabled on all network devices and ICT equipment.
  794. IPv6 tunnelling is blocked by network security devices at externally-connected network boundaries.
  795. Dynamically assigned IPv6 addresses are configured with Dynamic Host Configuration Protocol version 6 in a stateful manner with lease data stored in a centralised logging facility.
  796. Network access controls are implemented on networks to prevent the connection of unauthorised network devices.
  797. Network access controls are implemented to limit traffic within and between network segments to only those that are required for business purposes.
  798. A network device register is maintained and regularly audited.
  799. Default accounts for network devices are disabled, renamed or have their passphrase changed.
  800. Unused physical ports on network devices are disabled.
  801. Servers maintain effective functional separation with other servers allowing them to operate independently.
  802. Servers minimise communications with other servers at both the network and file system level.
  803. Security measures are implemented to prevent unauthorised access to network management traffic.
  804. SNMP version 1 and 2 are not used on networks.
  805. All default SNMP community strings on network devices are changed and have write access disabled.
  806. NIDS or NIPS are deployed in all gateways between an organisation’s networks and other networks they do not manage.
  807. NIDS or NIPS in gateways are located immediately inside the outermost firewall and configured to generate a log entry, and an alert, for any data flows that contravene any rule in firewall rule sets.
  808. When deploying NIDS or NIPS in non-internet gateways, they are configured to monitor unusual patterns of behaviour or traffic flows rather than internet-based communication protocol signatures.
  809. Inbound network connections from anonymity networks to internet-facing services are blocked.
  810. Outbound network connections to anonymity networks are blocked.
  811. All wireless devices are Wi-Fi Alliance certified.
  812. Wireless networks provided for the general public to access are segregated from all other networks.
  813. The administrative interface on wireless access points is disabled for wireless network connections.
  814. The default SSID of wireless access points is changed.
  815. The SSID of a non-public wireless network is not readily associated with an organisation, the location of their premises or the functionality of the wireless network.
  816. SSID broadcasting is enabled on wireless networks.
  817. Default accounts and passphrases of wireless devices are changed.
  818. Configuration settings for wireless devices are hardened.
  819. Static addressing is not used for assigning IP addresses on wireless networks.
  820. MAC address filtering is not used to restrict which devices can connect to wireless networks.
  821. WPA3-Enterprise 192-bit mode is used to protect the confidentiality and integrity of all wireless network traffic.
  822. 802.1X authentication with EAP-TLS, using X.509 certificates, is used for mutual authentication; with all other EAP methods disabled on supplications and authentication servers.
  823. User identity confidentiality is used if available with EAP-TLS implementations.
  824. Evaluated supplicants, authenticators, wireless access points and authentication servers are used in wireless networks.
  825. Certificates are generated using an evaluated certificate authority solution or hardware security module.
  826. Certificates are required for both devices and users accessing wireless networks.
  827. Certificates are protected by encryption, user authentication, and both logical and physical access controls.
  828. The PMK caching period is not set to greater than 1440 minutes (24 hours).
  829. The use of FT (802.11r) is disabled unless authenticator-to-authenticator communications are secured by an ASD Approved Cryptographic Protocol.
  830. Communications between authenticators and a RADIUS server are encapsulated with an additional layer of encryption using RADIUS over Internet Protocol Security or RADIUS over Transport Layer Security.
  831. Wireless networks implement sufficient frequency separation from other wireless networks.
  832. Wireless access points enable the use of the 802.11w amendment to protect management frames.
  833. Instead of deploying a small number of wireless access points that broadcast on high power, a greater number of wireless access points that use less broadcast power are deployed to achieve the desired footprint.
  834. The effective range of wireless communications outside an organisation’s area of control is limited by implementing RF shielding on facilities in which SECRET or TOP SECRET wireless networks are used.
  835. A cloud service provider is used for hosting online services.
  836. Organisations are notified by cloud service providers of any change to configured regions or availability zones for online services.
  837. Cloud service providers’ ability to dynamically scale resources due to a genuine spike in demand or a denial-of-service attack is tested as part of capacity planning processes for online services.
  838. Where a high availability requirement exists for online services, the services are architected to automatically transition between availability zones.
  839. Where a requirement for high availability exists for online services, a denial of service mitigation service is used.
  840. Organisations perform continuous real-time monitoring of the availability of online services.
  841. Where a high availability requirement exists for website hosting, CDNs that cache websites are used.
  842. If using a CDN, disclosing the IP address of the web server under the organisation’s control (referred to as the origin server) is avoided and access to the origin server is restricted to the CDN and an authorised management network.
  843. "Denial-of-service attack prevention and mitigation strategies are discussed with cloud service providers, specifically:
  844. • their capacity to withstand denial-of-service attacks
  845. • any costs likely to be incurred as a result of denial-of-service attacks
  846. • thresholds for notification of denial-of-service attacks
  847. • thresholds for turning off online services during denial-of-service attacks
  848. • pre-approved actions that can be undertaken during denial-of-service attacks
  849. • denial-of-service attack prevention arrangements with upstream service providers to block malicious traffic as far upstream as possible."
  850. The functionality and quality of online services, how to maintain such functionality, and what functionality can be lived without during a denial-of-service attack, are determined and documented.
  851. Domain names for online services are protected via registrar locking and confirming domain registration details are correct.
  852. Availability monitoring with real-time alerting is implemented for online services to detect denial-of-service attacks and measure their impact.
  853. Critical online services are segregated from other online services that are more likely to be targeted.
  854. A static version of a website is pre-prepared that requires minimal processing and bandwidth in order to facilitate at least a basic level of service when under a denial-of-service attack.
  855. Encryption software that has completed a Common Criteria evaluation against a Protection Profile is used when encrypting media that contains OFFICIAL: Sensitive or PROTECTED data.
  856. HACE is used when encrypting media that contains SECRET or TOP SECRET data.
  857. Full disk encryption, or partial encryption where access controls will only allow writing to the encrypted partition, is implemented when encrypting data at rest.
  858. In addition to any encryption already in place, an ASD Approved Cryptographic Algorithm (AACA) is used to encrypt AUSTEO and AGAO data when at rest on a system.
  859. Where practical, cryptographic equipment and encryption software provides a means of data recovery to allow for circumstances where the encryption key is unavailable due to loss, damage or failure.
  860. When a user authenticates to encryption functionality for ICT equipment or media storing encrypted data, it is treated in accordance with its original sensitivity or classification until such a time that the user deauthenticates from the encryption functionality.
  861. Cryptographic equipment or encryption software that has completed a Common Criteria evaluation against a Protection Profile is used to protect OFFICIAL: Sensitive or PROTECTED data when communicated over insufficiently secure networks, outside of appropriately secure areas or via public network infrastructure.
  862. HACE is used to protect SECRET and TOP SECRET data when communicated over insufficiently secure networks, outside of appropriately secure areas or via public network infrastructure.
  863. In addition to any encryption already in place, an ASD Approved Cryptographic Protocol (AACP) is used to protect AUSTEO and AGAO data when communicated across network infrastructure.
  864. Only AACAs or high assurance cryptographic algorithms are used by cryptographic equipment and software.
  865. ECDH and ECDSA are used in preference to DH and DSA.
  866. When using DH for agreeing on encryption session keys, a modulus of at least 2048 bits is used.
  867. When using DH for agreeing on encryption session keys, a modulus and associated parameters are selected according to NIST SP 800-56A Rev. 3.
  868. When using DSA for digital signatures, a modulus of at least 2048 bits is used.
  869. When using DSA for digital signatures, a modulus and associated parameters are generated according to FIPS 186-4.
  870. When using elliptic curve cryptography, a curve from FIPS 186-4 is used.
  871. When using ECDH for agreeing on encryption session keys, a base point order and key size of at least 224 bits is used.
  872. When using ECDSA for digital signatures, a base point order and key size of at least 224 bits is used.
  873. When using RSA for digital signatures, and passing encryption session keys or similar keys, a modulus of at least 2048 bits is used.
  874. When using RSA for digital signatures, and for passing encryption session keys or similar keys, a key pair for passing encrypted session keys that is different from the key pair used for digital signatures is used.
  875. Symmetric cryptographic algorithms are not used in Electronic Codebook Mode.
  876. AACAs used by HACE are implemented in an ASD approved configuration, with preference given to CNSA Suite algorithms and key sizes.
  877. Only AACPs or high assurance cryptographic protocols are used by cryptographic equipment and software.
  878. Only the latest version of TLS is used.
  879. AES in Galois Counter Mode is used for symmetric encryption.
  880. Only server-initiated secure renegotiation is used.
  881. DH or ECDH is used for key establishment.
  882. When using DH or ECDH for key establishment, the ephemeral variant is used.
  883. Anonymous DH is not used.
  884. SHA-2-based certificates are used.
  885. Cipher suites are configured to use SHA-2 as part of the Message Authentication Code and Pseudo-Random Function.
  886. TLS compression is disabled.
  887. PFS is used for TLS connections.
  888. The use of SSH version 1 is disabled.
  889. "The SSH daemon is configured to:
  890. • only listen on the required interfaces (ListenAddress xxx.xxx.xxx.xxx)
  891. • have a suitable login banner (Banner x)
  892. • have a login authentication timeout of no more than 60 seconds (LoginGraceTime 60)
  893. • disable host-based authentication (HostbasedAuthentication no)
  894. • disable rhosts-based authentication (IgnoreRhosts yes)
  895. • disable the ability to login directly as root (PermitRootLogin no)
  896. • disable empty passwords (PermitEmptyPasswords no)
  897. • disable connection forwarding (AllowTCPForwarding no)
  898. • disable gateway ports (GatewayPorts no)
  899. • disable X11 forwarding (X11Forwarding no)."
  900. Public key-based authentication is used for SSH connections.
  901. SSH private keys are protected with a passphrase or a key encryption key.
  902. "When using logins without a passphrase for automated purposes, the following are disabled:
  903. • access from IP addresses that do not require access
  904. • port forwarding
  905. • agent credential forwarding
  906. • X11 display remoting
  907. • console access."
  908. If using remote access without the use of a passphrase, the ‘forced command’ option is used to specify what command is executed and parameter checked is enabled.
  909. When SSH-agent or other similar key caching programs are used, it is only on workstations and servers with screen locks, key caches are set to expire within four hours of inactivity, and agent credential forwarding is enabled only when SSH traversal is required.
  910. Versions of S/MIME earlier than 3.0 are not used.
  911. Tunnel mode is used for IPsec connections; however, if using transport mode, an IP tunnel is used.
  912. The ESP protocol is used for IPsec connections.
  913. IKE is used for key exchange when establishing an IPsec connection.
  914. If using ISAKMP in IKE version 1, aggressive mode is disabled.
  915. A security association lifetime of less than four hours, or 14400 seconds, is used.
  916. HMAC-SHA256, HMAC-SHA384 or HMAC-SHA512 is used as a HMAC algorithm.
  917. The largest modulus size possible for all relevant components in the network is used when conducting a key exchange.
  918. PFS is used for IPsec connections.
  919. The use of XAuth is disabled for IPsec connections using IKE version 1.
  920. Keyed cryptographic equipment is transported based on the sensitivity or classification of the keying material in it.
  921. The compromise or suspected compromise of cryptographic equipment or associated keying material is reported to an organisation’s Chief Information Security Officer, or one of their delegates, as soon as possible after it occurs.
  922. Keying material is changed when compromised or suspected of being compromised.
  923. All communications security and equipment-specific doctrine produced by the ACSC for the management and use of HACE is complied with.
  924. Areas in which HACE is used are separated from other areas and designated as a cryptographic controlled area.
  925. All systems are protected from systems in other security domains by one or more gateways.
  926. All connections between security domains implement mechanisms to inspect and filter data flows for the transport and higher layers as defined in the OSI model.
  927. "Gateways:
  928. • are the only communications paths into and out of internal networks
  929. • allow only explicitly authorised connections
  930. • are managed via a secure path isolated from all connected networks (physically at the gateway or on a dedicated administration network)
  931. • log all physical and logical access to their components
  932. • are configured to save logs to a secure logging facility
  933. • have all security controls tested to verify their effectiveness after any changes to their configuration."
  934. Gateways implement ingress traffic filtering to detect and prevent Internet Protocol (IP) source address spoofing.
  935. "All gateways connecting networks in different security domains are operated such that they:
  936. • log network traffic permitted through the gateway
  937. • log network traffic attempting to leave the gateway
  938. • are configured to save event logs to a secure logging facility
  939. • provide real-time alerts for any cyber security incidents, attempted intrusions and unusual usage patterns."
  940. Demilitarised zones are used to broker access to services accessed by external entities, and mechanisms are applied to mediate internal and external access to less-trusted services hosted in these demilitarised zones.
  941. Gateways are subject to rigorous testing, performed at irregular intervals no more than six months apart, to determine the strength of security controls.
  942. Access to gateway administration functions is limited to the minimum roles and privileges to support the gateway securely.
  943. System administrators are formally trained to manage gateways.
  944. All system administrators of gateways are cleared to access the highest level of data communicated or processed by the gateway.
  945. All system administrators of gateways that process Australian Eyes Only or Australian Government Access Only data are Australian nationals.
  946. Roles for the administration of gateways are separated.
  947. For gateways between networks in different security domains, a formal arrangement exists whereby any shared components are managed by the system managers of the highest security domain or by a mutually agreed third party.
  948. Once connectivity is established, system owners become stakeholders for all connected security domains.
  949. Users and services accessing networks through gateways are authenticated.
  950. Only users and services authenticated and authorised to a gateway can use the gateway.
  951. Multi-factor authentication is used for access to gateways.
  952. ICT equipment accessing networks through gateways is authenticated.
  953. When connecting a SECRET or TOP SECRET network to any other network from a different security domain, a CDS is implemented.
  954. When designing and deploying a CDS, the ACSC is notified and consulted; and directions provided by the ACSC are complied with.
  955. When introducing additional connectivity to a CDS, such as adding a new gateway to a common network, the ACSC is consulted on the impact to the security of the CDS; and directions provided by the ACSC are complied with.
  956. A CDS implements isolated upward and downward network paths.
  957. A CDS implements protocol breaks at each layer of the OSI model.
  958. A CDS implements content filtering and separate independent security-enforcing components for upward and downward data flows.
  959. All security-relevant events generated by a CDS are logged and regularly analysed.
  960. A representative sample of security events generated by a CDS, relating to the enforcement of data transfer policies, is taken at least every 3 months and assessed against the security policies that the CDS is responsible for enforcing between security domains.
  961. Users are trained on the secure use of a CDS before access to the CDS is granted.
  962. An evaluated firewall is used between organisations’ networks and public network infrastructure.
  963. An evaluated firewall is used between networks belonging to different security domains.
  964. The requirement to use a firewall as part of gateway infrastructure is met by both parties independently; shared ICT equipment does not satisfy the requirements of both parties.
  965. An evaluated diode is used for controlling the data flow of a unidirectional gateway between an organisation’s network and public network infrastructure.
  966. An evaluated diode used for controlling the data flow of a unidirectional gateway between a SECRET or TOP SECRET network and public network infrastructure completes a high assurance evaluation.
  967. An evaluated diode is used for controlling the data flow of a unidirectional gateway between networks.
  968. An evaluated diode used for controlling the data flow of a unidirectional gateway between a SECRET or TOP SECRET network and any other network completes a high assurance evaluation.
  969. A diode (or server connected to the diode) deployed to control data flow in unidirectional gateways monitors the volume of the data being transferred.
  970. A web usage policy is developed and implemented.
  971. All web access, including that by internal servers, is conducted through a web proxy.
  972. "A web proxy authenticates users and provides logging that includes the following details about websites accessed:
  973. • address (uniform resource locator)
  974. • time/date
  975. • user
  976. • amount of data uploaded and downloaded
  977. • internal and external IP addresses."
  978. A web content filter is used to filter potentially harmful web-based content.
  979. Client-side active content, such as Java, is restricted to a list of allowed websites.
  980. Web content filtering controls are applied to outbound web traffic where appropriate.
  981. "For TLS traffic communicated through internet gateways, either of the following approaches are implemented:
  982. • a solution that decrypts and inspects all TLS traffic as per content filtering security controls
  983. • a list of websites to which encrypted connections are allowed, with all other TLS traffic decrypted and inspected as per content filtering security controls."
  984. Legal advice is sought regarding the inspection of TLS traffic by internet gateways.
  985. A list of allowed websites, using either domain name or IP address, is implemented for all Hypertext Transfer Protocol and Hypertext Transfer Protocol Secure traffic communicated through internet gateways.
  986. If a list of allowed websites is not implemented, a list of allowed website categories is implemented instead.
  987. If a list of allowed websites is not implemented, a list of blocked websites is implemented instead.
  988. If a list of blocked websites is implemented, the list is updated on a daily basis to ensure that it remains effective.
  989. Attempts to access a website through its IP address instead of through its domain name are blocked.
  990. Dynamic domains and other domains where domain names can be registered anonymously for free are blocked.
  991. When importing data into a security domain, the data is filtered by a content filter designed for that purpose.
  992. Content filters deployed in a CDS are subject to rigorous security assessment to ensure they mitigate content-based threats and cannot be bypassed.
  993. All suspicious, malicious and active content is blocked from entering a security domain.
  994. Any data identified by a content filtering process as suspicious is blocked until reviewed and approved for transfer by a trusted source other than the originator.
  995. Email and web content entering a security domain is automatically run in a dynamic malware analysis sandbox to detect suspicious behaviour.
  996. Content validation is performed on all data passing through a content filter with content which fails content validation blocked.
  997. Content conversion is performed for all ingress or egress data transiting a security domain boundary.
  998. Content sanitisation is performed on suitable file types if content conversion is not appropriate for data transiting a security domain boundary.
  999. Antivirus scanning, using multiple different scanning engines, is performed on all content.
  1000. The contents from archive/container files are extracted and subjected to content filter checks.
  1001. Controlled inspection of archive/container files is performed to ensure that content filter performance or availability is not adversely affected.
  1002. Files that cannot be inspected are blocked and generate an alert or notification.
  1003. A list of allowed content types is implemented.
  1004. The integrity of content is verified where applicable and blocked if verification fails.
  1005. If data is signed, the signature is validated before the data is exported.
  1006. All encrypted content, traffic and data is decrypted and inspected to allow content filtering.
  1007. An evaluated peripheral switch is used when sharing peripherals between systems.
  1008. An evaluated peripheral switch used for sharing peripherals between SECRET and TOP SECRET systems, or between SECRET or TOP SECRET systems belonging to different security domains, preferably completes a high assurance evaluation.
  1009. An evaluated peripheral switch used for sharing peripherals between SECRET or TOP SECRET systems and any non-SECRET or TOP SECRET systems completes a high assurance evaluation.
  1010. Data transfer processes, and supporting data transfer procedures, are developed and implemented.
  1011. Users transferring data to and from a system are held accountable for the data they transfer.
  1012. All data transferred from a SECRET or TOP SECRET system to any other system is reviewed and approved by a trusted source.
  1013. A trusted source signs all data authorised for export from a SECRET or TOP SECRET system.
  1014. Trusted sources for SECRET and TOP SECRET systems are limited to people and services that have been authorised as such by an organisation’s Chief Information Security Officer.
  1015. Data imported to a system is scanned for malicious and active content.
  1016. Data imported to a SECRET or TOP SECRET system undergoes data format checks and logging, and is monitored to detect overuse/unusual usage patterns.
  1017. When exporting data from a system, protective marking checks are undertaken.
  1018. "When exporting data from a SECRET or TOP SECRET system, the following activities are undertaken:
  1019. • data format checks and logging
  1020. • monitoring to detect overuse/unusual usage patterns
  1021. • limitations on data types and sizes
  1022. • keyword searches on all textual data."
  1023. Processes, and supporting procedures, are developed and implemented to prevent AUSTEO and AGAO data in both textual and non-textual formats from being exported to foreign systems.
  1024. When exporting AUSTEO or AGAO data from a system, keyword searches are undertaken on all textual data and any identified data is quarantined until reviewed and approved for release by a trusted source other than the originator.
  1025. Data transfer logs are used to record all data imports and exports from systems.
  1026. Data transfer logs for systems are partially audited at least monthly.
  1027. Data transfer logs for SECRET and TOP SECRET systems are fully audited at least monthly.
  1028.  
Add Comment
Please, Sign In to add comment