14
RESPONSIBILITIES
15
IdAM addresses the policies and technical practices defined by a data owner, vetted by 16
governance and oversight bodies, and enacted by a system owner to protect the information 17
contained in the system. These policies and technical practices must be incorporated into the 18
business practices of the system owner, implemented in the technical capabilities of the system, 19
and enforced as users’ access and use the system. As IdAM capabilities become more robust for 1
identifying users and their business purpose in accessing system information, the security model 2
for the system should evolve to take advantage of the additional opportunities for safeguarding 3
system information through fine-grained access control. 4
Executives must recognize the value of implementing reusable (sharable) IdAM services for 5
mission systems and must reinforce the value provided by such services to their organization 6
through the support of an organizational EA function, aligned with larger federal EA efforts, that 7
identifies and incorporates such shared services. Program Managers must ensure that their 8
system engineering lifecycle incorporates their organization’s architecture considerations, as well 9
as larger federal enterprise considerations. The Program Manager must ensure that the 10
requirements for the system incorporate interfaces for external IdAM services so that reusable 11
enterprise shared services can be leveraged for the mission system, and that the timeline for use 12
of such services is aligned with the organizational or federal roadmap and timeline for 13
implementation for those services. The Solution Architect will need to create a system that 14
provides flexible interfaces to interoperate with IdAM and security services and standards. Those 15
interfaces must adapt as those services and standards evolve during the lifecycle of the system. 16
Data Architects, working with the relevant Data Owners, must ensure that data is accurately 17
tagged in such a way that access control may be maintained over it. An effective access control 18
capability must know certain things about each piece of data, such as its sensitivity, releaseability, 19
or copyright restrictions. These requirements must be incorporated into a data tagging 20
methodology, in alignment with relevant data standards, and built into the system. 21
System owners must work to balance safeguarding and sharing through appropriate risk 22
management measures, applying IdAM’s safeguarding capabilities close to their data and system 23
while additionally leveraging those employed by the fabric, network, or environment as a whole. 24
The security concept for the system should reflect that environment, using the security of the 25
surrounding environment to complement the local system security to provide defense in depth. 26
Network-wide security measures are necessary supporting elements of security, but are not 27
sufficient on their own to satisfy modern information safeguarding needs. 28
Significant stakeholders in IdAM are diverse and include Data and Mission Owners, Program and 29
Project Managers, System Owners, Enterprise Architects, Information Assurance, and even 30
Procurement personnel. 31
• Data and Mission Owners – are responsible for determining, in plain English, the 32
access control policies for the data they maintain stewardship over. Does their data 33
require users to be from a certain part of the organization? Perhaps have a certain 34
security clearance or have taken certain training? Can their information be accessed 35
by others outside of their Department or Agency? Under what circumstances? 36
◦ These policies must be developed in coordination with, and often approved by, 1
some sort of Governance or Oversight body that often includes General Counsel, 2
the Privacy Office, and others involved in legal and regulatory activities. 3
• Program and Project Managers – are responsible for ensuring the system lifecycle, 4
beginning with the requirements definition through the design and 5
implementation, incorporates the capabilities necessary to meet IdAM and Security 6
requirements for their systems and ensuring that the funding for such capabilities is 7
provided for in the system budget planning. 8
• System Owners – are responsible for ensuring that their systems implement the 9
access control policies defined by Data Owners, as well as for ensuring that their 10
systems implement only the FICAM Service Types that can’t be shared. 11
◦ The FICAM Roadmap lists the following service types: Digital Identity, 12
Credentialing, Privilege Management, Authentication, Authorization and Access, 13
Cryptography, and Auditing and Reporting. 14
◦ A system owner should generally not need to address Digital Identity or 15
Credentialing, as those service types can generally be implemented at the 16
organizational level and shared. System owners may need to incorporate pieces 17
and parts of Privilege Management, Authorization and Access, Auditing and 18
Reporting, and aspects of both Authentication and Cryptography into their 19
system lifecycle. 20
• Enterprise Architects – are responsible for ensuring that shared IdAM-related 21
services are known about and, where appropriate, re-used. Does an in-progress 22
project truly need to have all of its own internal IdAM services? Can it re-use an 23
existing enterprise service? 24
• Information Assurance Personnel – are responsible for ensuring that IdAM is 25
implemented properly, when a shared service is first constructed, when it is re- 26
used, and when a system builds its own internal capabilities. 27
• Procurement Personnel – are responsible for ensuring that IT procurements 28
incorporate the right standards, allowing a system to leverage a shared IdAM 29
service. These personnel are also responsible for ensuring that requests for 30
proposal indicate the desired re-use. 31
System owners should focus on the IdAM service types inherent to their system, and should 32
leverage reusable services where applicable. Certain FICAM Service Components may be provided 33
by enterprise capabilities (e.g., cryptography for classified communications security) or by shared 34
capabilities (e.g., shared PKI services), and implementers should examine each of the FICAM 35
Service Components, taking into account the security domain on which they operate, to 36
determine which should be reused and which should be built within their system. This “focus on 37
the system” approach allows the system owner to protect their systems, and data, more robustly 1
than either the traditional perimeter network defense model or a situation where the 2
implementer must account for all FICAM Service Components on their own. 3