ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
2
AARC-G071 Guidelines for Secure Operation of Attribute Authorities and issuers of statements for entities review sheet
3
Operator
Peers:
4
AA scope
5
Model
6
Product(s)
7
InteropDate of last update:
8
9
This assessment sheet supports the evaluation of the AARC-G071 "AAOPS" guidelines. Please refer to the Guidelines document https://aarc-community.org/guidelines/aarc-g071/ for the full description, requirements, and supporting documentation. Please clone this sheet for your own assessment.
10
11
12
ItemDescriptionStatusReferencesReview comments
13
OK, PARTIAL, N/Alink to document(s) and/or description of implementation, or substantiationsuggestions (by self or peers) on recommendations, next steps, and planned changes
14
AN-1Identifiers of the AA Operator and the AA must both be non-reassigned and globally unique.
15
AN-1.2In addition, the identifier of the Community should be unique.
16
AN-1.3Community User Identifiers for subjects and attributes should be chosen in accordance with the AARC Guidelines and the Community Membership Management policy [AARC-G003].
17
AN-1.4The AA must use a defined naming scheme for subjects and attributes.
18
AN-1.5Subject identifiers must be non-reassigned and unique within an AA.
19
AMR-1The Community must define and document the semantics, lifecycle, data protection, and release policy of attributes stored or asserted by the AA.
20
AMR-1.2semantics
21
AMR-1.3lifecycle
22
AMR-1.4data protection
23
AMR-1.5attribute release policy
24
AMR-2The AA Operator must implement the community definitions as defined and documented, for all the AAs it operates.
25
AMR-3It is recommended that the AA Operator provide a capability for the community to publish documents defining the attribute set and the semantics used by the community, for the benefit of Relying Parties.
26
AMR-4The AA must only issue assertions or release attributes in accordance with the policies that are applicable to the Community
27
AMR-5When a community engages multiple AA Operators or operates multiple AAs, the community must ensure that the assertions issued are consistent between all issuers.
28
AMR-6The community should ensure that within one assertion issued attributes are consistent.
29
AAS-1Assertions provided by an AA must be integrity-protected. They must be signed by the identified AA, or be transmitted over an integrity-protected channel where the server has been authenticated, and preferably both.
30
AAS-2In addition to meeting its own regulatory obligations, the AA must respect data protection requirements of the Community.
31
AAS-2.2It is recommended that AAs require client authentication, in addition to the encryption of the messages and the communication channel.
32
AAS-2.3The AA should not send more data than required by the RP.
33
AAS-3If an AA Operator issues assertions containing a lifetime, this lifetime must be compliant with the Community policies, as short as reasonably possible, and the assertion must not be valid beyond the validity period of the attributes it contains. The Community Management is responsible for the content of the assertion, as issued, during its entire lifetime
34
AAS-4Re-issuance of assertions must be based on information held in the AA at the time of re-issuance.
35
OEImplementers of AAs should use placement policies to ensure physical and/or virtual separation of sensitive and non-sensitive services, containers, or virtual machines, to reduce the risk of cross-compromise, taking into account both the integrity of the AA as well as the requirements of the communities hosted on the AA and the Relying Parties receiving attributes
36
OE-1Through its personnel or by contractual measures, the AA Operator should ensure appropriate controls are in place over the security context.
37
OE-2The AA must be located in a physically secure environment where access is controlled and limited to specific trained personnel.
38
OE-3The protections on the AA and its operational environment, including the credentials of the AA administrators and operators, should meet or exceed the requirements of all of the communities hosted in the AA.
39
KM-1A key used to protect assertions should be dedicated to assertion protection functions.
40
KM-2Keys must not be shared between AA Operators. A single AA Operator may use the same signing key for multiple AAs. Where multiple AAs are under the control of a single AA operator but located in physically distributed locations, the key must only be transported using secure protocols.
41
KM-3Keys must have a protection strength equivalent to 112 bits (symmetric) or higher.
42
KM-4Keys must only be accessible by the service and by trained personnel subject to procedural controls.
43
KM-5AA Operators are recommended to use an HSM to store signing keys.
44
KM-5.2When using software-based private keys, such keys must be suitably protected by the operating system. Keys should not be held unencrypted on persistent storage protected solely by database, storage and file system level permissions.
45
NET-1The network to which the AA system is connected must be highly protected and suitably monitored.
46
SITE-1The AA Operator must ensure appropriate site security controls are in place and maintained in a state consistent with the security requirements of the hosted Communities.
47
MD-1The AA Operator must publish, to the Community and related Relying Parties, at least the following metadata for each AA it hosts
[generic requirement: the AA operator has a meta-data publishing end-point]
48
MD-1.1aadministrative contact details for the AA Operator, including at least one role-based email address and one postal contact address
49
MD-1.1ban operational security contact for the AA Operator, being at least a role-based email address but preferably including a telephone number
50
MD-1.1ccryptographic key material required to verify signed messages, where that is required to validate issued attribute assertions
51
MD-2It is recommended that the AA Operator publishes, where available
[generic requirement: the AA operator has a web site]
52
MD-2.1asuch validated trust marks as are relevant to the evaluation of the security and trust of the AA by the Communities, Identity Providers, and Relying Parties
53
MD-2.1ba (web) URL to a general information web page about the Community.
54
MD-3The AA Operator should provide a means to validate the integrity of its roots of trust.
55
AR-1The attributes in the AA and their binding to subjects must be verifiable and assessable.
56
AR-2The AA Operator must log, for the purpose of traceability in support of security incident response, where the AA provides relevant attributes, at least the following for all of its hosted AAs
57
AR-2.1aall requests for attributes and all issued attribute assertions, to the extent that they are needed to allow traceability of attribute release to individuals during incident response by receiving qualified Relying Parties
58
AR-2.1bany configuration change to the AA relevant to the access control of the attribute repository
59
AR-2.1cany change affecting the binding between subjects and attributes
60
AR-2.2The AA Operator, in its published privacy and confidentiality policies must permit logging as required above.
61
AR-3The AA Operator must log at least the following for its AA issuance systems, for the purposes of incident response:
62
AR-3.1aall login, logout, reboot, and key activation events of the issuing system
63
AR-3.1bchanges to the configuration of the issuing system
64
AR-4The AA Operator must keep records regarding attribute release and its issuance systems after termination of the effects of the auditable events for as long as required by the Community and any Relying Parties that have entered into an agreement with the AA Operator, and as required by applicable legislation.
65
AR-5The AA operator must disclose and discuss, on request, those aspects of their operational environment that are relevant to the evaluation of the security and trust by the Communities and Relying Parties
66
AR-6The AA Operator must be able and willing to collaborate with affected organisations in the management of a security incident
67
AR-7The AA Operator should review roles, rights, and access of its staff at least once per year
68
PC-1The AA operator must define and publish a privacy and data release policy, and that policy must be compatible with the assertions that it issues, and be compliant with relevant legislation
69
BCDR-1The AA Operator must have a compromise and disaster recovery procedure ...
70
BCDR-1.2... and a business continuity plan
71
BCDR-2The business continuity and disaster recovery plan must be compatible with the requirements of the hosted Communities.
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100