From 4f6a02ff139b97a99a2ee1893b5962e8acda9a7c Mon Sep 17 00:00:00 2001 From: TimGoodwill <51429996+TimGoodwill@users.noreply.github.com> Date: Wed, 16 Sep 2020 14:45:03 +1000 Subject: [PATCH 1/7] Addition of Protected Marking sub-section to api-security.md, as discussed Working Group July 27 Addition of Protected Marking sub-section to API Security, as discussed Working Group July 27 --- sections/api-security.md | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/sections/api-security.md b/sections/api-security.md index 4b75724..eaf1893 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -31,12 +31,12 @@ Depending on the security classification you may be required to establish the fo ## Authentication and Authorization - Basic or Digest authentication **SHOULD NOT** be used. -- The `Authorization: Bearer` header **MUST** be used for authentication/authorization e.g. using a JWT token. +- The `Authorization: Bearer` header **MUST** be used for authentication/authorization e.g. using a JWT token. Authorization tokens identify a user — the person — that is using the app or site. - A refresh token **SHOULD** be provided for extending expiry time of existing token without having to provide the credentials again. - Always set a reasonable expiration date for tokens. JWT token lifetime **SHOULD NOT*** exceed 5 minutes. - JWT refresh tokens **SHOULD** be used when new JWT tokens are required outside of this lifetime. - All APIs **MUST** have a policy that only allows access based on a valid API key. -- API keys **MUST** be used for client authentication. Use of API keys should only be permitted when TLS is enabled. Rotation policy for API Key should be implemented as well. +- API keys **MUST** be used for client identification. Use of API keys should only be permitted when TLS is enabled. Rotation policy for API Key should be implemented as well. API keys identify the calling project — the application or site — making the call to an API. - API keys **SHOULD NOT** be included in the URL or query string. API keys **SHOULD** be included in the HTTP header as query strings may be saved by the client or server in unencrypted format by the browser or server application. - CORS headers should only be used when necessary as it reduce overall security mechanisms built into web browsers by selectively relaxing cross-origin restrictions. - A request from Domain A is considered cross-origin when it tries to make a request to an API that is hosted in Domain B. @@ -129,3 +129,28 @@ It is preferable to use the security policy features available in the WoG API Ga | CORS | Listeners-\>Path | CORS can be restricted at path level | Recommended | The WoG API Team can provide advice on which API Gateway security policies should be applied. + +## Protective Marking + +Commonwealth entities, and State and territory government agencies that hold or access Commonwealth security classified information are required by the Protective Security Policy Framework to apply appropriate protective marking to classified data to ensure that data is handled and shared appropriately. +An ‘x-protective-marking’ HTTP header MUST be used to apply appropriate protective marking to Commonwealth security classified information. + +The following rules apply to the use of the ‘x-protective-marking’ header: +• Transmission of any payload, request or response, containing data classified as having a high business impact level (‘PROTECTED’ at the time of writing) or above MUST be accompanied by an ‘x-protective-marking’ HTTP header. +• Data classified as having a ‘low to medium’ business impact (‘OFFICIAL:Sensitive’ at the time of writing) or above SHOULD be accompanied by an ‘x-protective-marking’ HTTP header, wherever technically feasible. + +The values (and case) of the header should align with the appropriate Security classification literals defined in the [Protective Security Policy Framework](https://www.protectivesecurity.gov.au/information/sensitive-classified-information/Pages/default.aspx), and conforming to the syntax prescribed in the [Annex B Email protective marking standard](https://www.protectivesecurity.gov.au/sites/default/files/2019-09/infosec08-sensitive-and-classified-information-email.pdf). + +**Syntax** +``` +X-Protective-Marking: VER=, NS=gov.au, SEC=(, CAVEAT=:)*(, EXPIRES=(|), DOWNTO=())?(, ACCESS=)* +``` + +The first 2 key-value pairs are largely static. The namespace ('NS') value is always ’gov.au' when produced by Australian Government entities. The version (‘VER’) of the PSPF will change infrequently. At the time of writing, the first 2 key-value pairs appended to the x-protective-marking header will be 'VER=2018.1' and 'NS=gov.au', followed by the security classification marker and further optional markings. + +e.g. +` x-protective-marking: VER=2018.1, NS=gov.au, SEC=PROTECTED` +or + ` x-protective-marking: VER=2018.1, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Personal-Privacy` + +Content (payload) classified as having a high business impact level or above MUST NOT be logged, unless over secure channels and to platforms approved for the retention of data to the appropriate classification. From 5c10cd3775815e11820a5a25d3833d43e5af67e5 Mon Sep 17 00:00:00 2001 From: TimGoodwill <51429996+TimGoodwill@users.noreply.github.com> Date: Tue, 17 Nov 2020 13:10:54 +1100 Subject: [PATCH 2/7] Update api-security.md --- sections/api-security.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sections/api-security.md b/sections/api-security.md index eaf1893..fbb2e1c 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -136,8 +136,8 @@ Commonwealth entities, and State and territory government agencies that hold or An ‘x-protective-marking’ HTTP header MUST be used to apply appropriate protective marking to Commonwealth security classified information. The following rules apply to the use of the ‘x-protective-marking’ header: -• Transmission of any payload, request or response, containing data classified as having a high business impact level (‘PROTECTED’ at the time of writing) or above MUST be accompanied by an ‘x-protective-marking’ HTTP header. -• Data classified as having a ‘low to medium’ business impact (‘OFFICIAL:Sensitive’ at the time of writing) or above SHOULD be accompanied by an ‘x-protective-marking’ HTTP header, wherever technically feasible. +- Transmission of any payload, request or response, containing data classified as having a high business impact level (‘PROTECTED’ at the time of writing) or above MUST be accompanied by an ‘x-protective-marking’ HTTP header. +- Data classified as having a ‘low to medium’ business impact (‘OFFICIAL:Sensitive’ at the time of writing) or above SHOULD be accompanied by an ‘x-protective-marking’ HTTP header, wherever technically feasible. The values (and case) of the header should align with the appropriate Security classification literals defined in the [Protective Security Policy Framework](https://www.protectivesecurity.gov.au/information/sensitive-classified-information/Pages/default.aspx), and conforming to the syntax prescribed in the [Annex B Email protective marking standard](https://www.protectivesecurity.gov.au/sites/default/files/2019-09/infosec08-sensitive-and-classified-information-email.pdf). From e60b81da5aa91211d4b7fd9cd7c7199c8e0dabb5 Mon Sep 17 00:00:00 2001 From: TimGoodwill <51429996+TimGoodwill@users.noreply.github.com> Date: Mon, 23 Nov 2020 14:09:57 +1100 Subject: [PATCH 3/7] Update api-security.md --- sections/api-security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sections/api-security.md b/sections/api-security.md index fbb2e1c..d21385f 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -31,7 +31,7 @@ Depending on the security classification you may be required to establish the fo ## Authentication and Authorization - Basic or Digest authentication **SHOULD NOT** be used. -- The `Authorization: Bearer` header **MUST** be used for authentication/authorization e.g. using a JWT token. Authorization tokens identify a user — the person — that is using the app or site. +- The `Authorization: Bearer` header **MUST** be used for authentication/authorization e.g. a JWT or opaque token. - A refresh token **SHOULD** be provided for extending expiry time of existing token without having to provide the credentials again. - Always set a reasonable expiration date for tokens. JWT token lifetime **SHOULD NOT*** exceed 5 minutes. - JWT refresh tokens **SHOULD** be used when new JWT tokens are required outside of this lifetime. From ed17ea17f56d0f995978c2e22b41cfb778536a80 Mon Sep 17 00:00:00 2001 From: TimGoodwill <51429996+TimGoodwill@users.noreply.github.com> Date: Mon, 30 Nov 2020 17:13:43 +1100 Subject: [PATCH 4/7] Update api-security.md --- sections/api-security.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sections/api-security.md b/sections/api-security.md index d21385f..26b9971 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -149,8 +149,11 @@ X-Protective-Marking: VER=, NS=gov.au, SEC=(, CAVEA The first 2 key-value pairs are largely static. The namespace ('NS') value is always ’gov.au' when produced by Australian Government entities. The version (‘VER’) of the PSPF will change infrequently. At the time of writing, the first 2 key-value pairs appended to the x-protective-marking header will be 'VER=2018.1' and 'NS=gov.au', followed by the security classification marker and further optional markings. e.g. + ` x-protective-marking: VER=2018.1, NS=gov.au, SEC=PROTECTED` + or + ` x-protective-marking: VER=2018.1, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Personal-Privacy` Content (payload) classified as having a high business impact level or above MUST NOT be logged, unless over secure channels and to platforms approved for the retention of data to the appropriate classification. From 6e235c45199ee3affe955aac92c3e228e4664311 Mon Sep 17 00:00:00 2001 From: TimGoodwill <51429996+TimGoodwill@users.noreply.github.com> Date: Mon, 30 Nov 2020 17:34:57 +1100 Subject: [PATCH 5/7] Update api-security.md --- sections/api-security.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sections/api-security.md b/sections/api-security.md index 26b9971..9fa8618 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -146,7 +146,7 @@ The values (and case) of the header should align with the appropriate Security c X-Protective-Marking: VER=, NS=gov.au, SEC=(, CAVEAT=:)*(, EXPIRES=(|), DOWNTO=())?(, ACCESS=)* ``` -The first 2 key-value pairs are largely static. The namespace ('NS') value is always ’gov.au' when produced by Australian Government entities. The version (‘VER’) of the PSPF will change infrequently. At the time of writing, the first 2 key-value pairs appended to the x-protective-marking header will be 'VER=2018.1' and 'NS=gov.au', followed by the security classification marker and further optional markings. +In the case of Commonwealth security classified information, the first 2 key-value pairs are largely static. The namespace ('NS') value is always 'gov.au' when produced by Australian Government entities. The version (‘VER’) of the PSPF will change infrequently. At the time of writing, the first 2 key-value pairs appended to the x-protective-marking header will be 'VER=2018.1' and 'NS=gov.au', followed by the security classification marker and further optional markings. e.g. @@ -156,4 +156,6 @@ or ` x-protective-marking: VER=2018.1, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Personal-Privacy` +State or territory governments may use the Australian Government (gov.au) namespace, or they may use a different namespace value from the Australian Government and apply rules specific to their jurisdiction. + Content (payload) classified as having a high business impact level or above MUST NOT be logged, unless over secure channels and to platforms approved for the retention of data to the appropriate classification. From 2aaca67f1c90ee9e31d210b9595766ed8263619a Mon Sep 17 00:00:00 2001 From: TimGoodwill <51429996+TimGoodwill@users.noreply.github.com> Date: Mon, 30 Nov 2020 17:37:22 +1100 Subject: [PATCH 6/7] Update api-security.md --- sections/api-security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sections/api-security.md b/sections/api-security.md index 9fa8618..14fa3b4 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -156,6 +156,6 @@ or ` x-protective-marking: VER=2018.1, NS=gov.au, SEC=OFFICIAL:Sensitive, ACCESS=Personal-Privacy` -State or territory governments may use the Australian Government (gov.au) namespace, or they may use a different namespace value from the Australian Government and apply rules specific to their jurisdiction. +State or territory governments may use the Australian Government (gov.au) namespace, or they may use a thier own namespace value (different from the Australian Government) and apply rules specific to their jurisdiction. Content (payload) classified as having a high business impact level or above MUST NOT be logged, unless over secure channels and to platforms approved for the retention of data to the appropriate classification. From d04403286335a2c161a2008c3378aee5130f4432 Mon Sep 17 00:00:00 2001 From: TimGoodwill <51429996+TimGoodwill@users.noreply.github.com> Date: Tue, 1 Dec 2020 10:46:43 +1100 Subject: [PATCH 7/7] Update api-security.md --- sections/api-security.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sections/api-security.md b/sections/api-security.md index 14fa3b4..ca0cac6 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -136,8 +136,8 @@ Commonwealth entities, and State and territory government agencies that hold or An ‘x-protective-marking’ HTTP header MUST be used to apply appropriate protective marking to Commonwealth security classified information. The following rules apply to the use of the ‘x-protective-marking’ header: -- Transmission of any payload, request or response, containing data classified as having a high business impact level (‘PROTECTED’ at the time of writing) or above MUST be accompanied by an ‘x-protective-marking’ HTTP header. -- Data classified as having a ‘low to medium’ business impact (‘OFFICIAL:Sensitive’ at the time of writing) or above SHOULD be accompanied by an ‘x-protective-marking’ HTTP header, wherever technically feasible. +- Transmission of any payload, request or response, containing data classified as having a high business impact level (Commonwealth classification of ‘PROTECTED’) or above MUST be accompanied by an ‘x-protective-marking’ HTTP header. +- Data classified as having a ‘low to medium’ business impact or above SHOULD be accompanied by an ‘x-protective-marking’ HTTP header, wherever technically feasible. The values (and case) of the header should align with the appropriate Security classification literals defined in the [Protective Security Policy Framework](https://www.protectivesecurity.gov.au/information/sensitive-classified-information/Pages/default.aspx), and conforming to the syntax prescribed in the [Annex B Email protective marking standard](https://www.protectivesecurity.gov.au/sites/default/files/2019-09/infosec08-sensitive-and-classified-information-email.pdf).