Use Case G: Service-Service Interactions#
Note
This page is supplementary material for the NIST SP 1800-35 publication.
This use case covers non-person entities and API calls between services. This covers automated processes as well. It is assumed MFA is not possible as there is no human subject involved in the session establishment. The enterprise should be able to uniquely identify (and authenticate) both the subject and resource in each test scenario. The method of this could vary and is not dictated in these scnearios. Endpoints where the service is running could be physical or virtual and include services running in containers.
Scenario G-1: Service Calls Between Resources#
This scenario demonstrates service-to-service communication between resources located on enterprise-operated infrastructure (on-prem or branch). Both resources (subject and requested resource) are considered authenticated and in compliance. The subject can be authorized or unauthorized to perform the action, as indicated in the table.
Pre-Condition: Two subjects, one authorized to perform the action and the other not authorized. All actors are in compliance with the enterprise security posture and authenticated to all relevant enterprise systems. All communications (successful and failed) are logged.
Demonstration: The subject system performs an action that involves an API call, or other service-to-service communication to another resource. All communication is logged.
Purpose and Outcome: This scenario demonstrates how the enterprise architecture prevents unauthorized communication between services and records all communication attempts (successful and prevented).
Table 1 - Scenario G-1 Demonstrations
Demo ID |
Subj. Location |
Authorized |
RSS Loc |
Desired Outcome |
|
|---|---|---|---|---|---|
G-1.1 |
a |
On-prem |
Yes |
On-Prem |
Access successful |
G-1.1 |
b |
On-prem |
No |
On-Prem |
Access not successful |
G-1.1 |
c |
Branch |
Yes |
On-Prem |
Access successful |
G-1.1 |
d |
Branch |
No |
On-Prem |
Access not successful |
G-1.1 |
e |
Remote (IaaS) |
Yes |
On-Prem |
Access successful |
G-1.1 |
f |
Remote (IaaS) |
No |
On-Prem |
Access not successful |
G-1.1 |
g |
Remote (PaaS) |
Yes |
On-Prem |
Access successful |
G-1.1 |
h |
Remote (PaaS) |
No |
On-Prem |
Access not successful |
G-1.1 |
i |
Remote (SaaS) |
Yes |
On-Prem |
Access successful |
G-1.1 |
j |
Remote (SaaS) |
No |
On-Prem |
Access not successful |
G-1.2 |
a |
On-prem |
Yes |
Branch |
Access successful |
G-1.2 |
b |
On-Prem |
No |
Branch |
Access not successful |
G-1.2 |
c |
Branch |
Yes |
Branch |
Access successful |
G-1.2 |
d |
Branch |
No |
Branch |
Access not successful |
G-1.2 |
e |
Remote (IaaS) |
Yes |
Branch |
Access successful |
G-1.2 |
f |
Remote (IaaS) |
No |
Branch |
Access not successful |
G-1.2 |
g |
Remote (PaaS) |
Yes |
Branch |
Access successful |
G-1.2 |
h |
Remote (Paas) |
No |
Branch |
Access not successful |
G-1.2 |
i |
Remote (SaaS) |
Yes |
Branch |
Access successful |
G-1.2 |
j |
Remote (Saas) |
No |
Branch |
Access not successful |
Scenario G-2: Service Calls to Cloud-Based Resources#
This scenario demonstrates service-to-service communication between resources located on enterprise-operated infrastructure (on-prem or branch) and cloud-based assets. Both resources (subject and requested resource) are considered authenticated and in compliance. The subject can be authorized or unauthorized to perform the action, as indicated in the table. The requested resource is IaaS, PaaS, or SaaS.
Pre-Condition: Two subjects, one authorized to perform the action and the other not authorized. All actors are in compliance and authenticated to all relevant enterprise systems. All communications (successful and failed) are logged.
Demonstration: The subject system performs an action that involves an API call or some other service-to-service communication to a resource. All communication is logged.
Purpose and Outcome: This scenario demonstrates how the enterprise architecture prevents unauthorized communication between services and records all communication attempts (successful and prevented).
Table 2 - Scenario G-2 Demonstrations
Demo ID |
Subj. Location |
Authorized |
RSS Type |
Desired Outcome |
|
|---|---|---|---|---|---|
G-2.1 |
a |
On-prem |
Yes |
IaaS |
Access successful |
G-2.1 |
b |
On-prem |
No |
IaaS |
Access not successful |
G-2.1 |
c |
Branch |
Yes |
IaaS |
Access successful |
G-2.1 |
d |
Branch |
No |
IaaS |
Access not successful |
G-2.1 |
e |
Remote |
Yes |
IaaS |
Access successful |
G-2.1 |
f |
Remote |
No |
IaaS |
Access not successful |
G-2.2 |
a |
On-prem |
Yes |
PaaS |
Access successful |
G-2.2 |
b |
On-prem |
No |
PaaS |
Access not successful |
G-2.2 |
c |
Branch |
Yes |
PaaS |
Access successful |
G-2.2 |
d |
Branch |
No |
PaaS |
Access not successful |
G-2.2 |
e |
Remote |
Yes |
PaaS |
Access successful |
G-2.2 |
f |
Remote |
No |
PaaS |
Access not successful |
G-2.3 |
a |
On-prem |
Yes |
SaaS |
Access successful |
G-2.3 |
b |
On-Prem |
No |
SaaS |
Access not successful |
G-2.3 |
c |
Branch |
Yes |
SaaS |
Access successful |
G-2.3 |
d |
Branch |
No |
SaaS |
Access not successful |
G-2.3 |
e |
Remote |
Yes |
SaaS |
Access successful |
G-2.3 |
f |
Remote |
No |
SaaS |
Access not successful |
Scenario G-3: Service Calls between Cloud-Based Resources#
This scenario demonstrates service-to-service communication between resources located on separate cloud-based resources. Both resources (subject and requested resource) are considered authenticated and in compliance. The subject can be authorized or unauthorized to perform the action, as indicated in the table. The resources are IaaS, PaaS, or SaaS.
Pre-Condition: Two subjects, one authorized to perform the action and the other not authorized. All actors are in compliance and authenticated to all relevant enterprise systems. All communications (successful and failed) are logged.
Demonstration: The subject system performs an action that involves an API call or some other service-to-service communication to a resource. All communication is logged.
Purpose and Outcome: This scenario demonstrates how the enterprise architecture prevents unauthorized communication between services and records all communication attempts (successful and prevented).
Table 3 - Scenario G-3 Demonstrations
Demo ID |
Subj. Type |
Authorized |
RSS Type |
Desired Outcome |
|
|---|---|---|---|---|---|
G-3.1 |
a |
IaaS |
Yes |
IaaS |
Access successful |
G-3.1 |
b |
IaaS |
No |
IaaS |
Access not successful |
G-3.1 |
c |
PaaS |
Yes |
IaaS |
Access successful |
G-3.1 |
d |
PaaS |
No |
IaaS |
Access not successful |
G-3.1 |
e |
SaaS |
Yes |
IaaS |
Access successful |
G-3.1 |
f |
SaaS |
No |
IaaS |
Access not successful |
G-3.2 |
a |
IaaS |
Yes |
PaaS |
Access successful |
G-3.2 |
b |
IaaS |
No |
PaaS |
Access not successful |
G-3.2 |
c |
PaaS |
Yes |
PaaS |
Access successful |
G-3.2 |
d |
PaaS |
No |
PaaS |
Access not successful |
G-3.2 |
e |
SaaS |
Yes |
PaaS |
Access successful |
G-3.2 |
f |
SaaS |
No |
PaaS |
Access not successful |
G-3.3 |
a |
IaaS |
Yes |
SaaS |
Access successful |
G-3.3 |
b |
IaaS |
No |
SaaS |
Access not successful |
G-3.3 |
c |
PaaS |
Yes |
SaaS |
Access successful |
G-3.3 |
d |
PaaS |
No |
SaaS |
Access not successful |
G-3.3 |
e |
SaaS |
Yes |
SaaS |
Access successful |
G-3.3 |
f |
SaaS |
No |
SaaS |
Access not successful |
Scenario G-4: Service Calls between Containers#
This scenario demonstrates service-to-service communication between resources located on separate containers, both in the same runtime or part of a larger Kubernetes pod(s) deployment. Both resources (subject and requested resource) are considered authenticated and in compliance. The subject can be authorized or unauthorized to perform the action, as indicated in the table. The subject is either another container in a single container runtime (e.g., Docker), in the same Kubernetes pod, or in a different Kubernetes pod from the requested resource.
Pre-Condition: Two subjects, one authorized to perform the action and the other unauthorized. All actors are in compliance and authenticated to all relevant enterprise systems. All communications (successful and failed) are logged.
Demonstration: The subject system performs an action that involves an API call or some other service-to-service communication to a resource. The enterprise can prevent unauthorized service-to-server communication. All communication is logged regardless of the outcome.
Purpose and Outcome: This scenario demonstrates how the enterprise architecture prevents unauthorized communication between services and records all communication attempts (successful and prevented).
Table 4 - Scenario G-4 Demonstrations
Demo ID |
Subj. Location |
Authorized |
Desired Outcome |
|
|---|---|---|---|---|
G-4.1 |
a |
Bare runtime |
Yes |
Access successful |
G-4.1 |
b |
Bare runtime |
No |
Access not successful |
G-4.1 |
c |
Separate pod |
Yes |
Access successful |
G-4.1 |
d |
Separate pod |
No |
Access not successful |
G-4.1 |
e |
Same pod |
Yes |
Access successful |
G-4.1 |
f |
Same pod |
No |
Access successful |
Scenario G-5: Service to Endpoint#
In this demonstration, an enterprise service reaches out to an enterprise managed endpoint to perform some action (e.g., maintenance, reconfiguration, etc.). User IDs are not directly involved in this scenario.
Pre-Condition: There is no active session from a subject to an enterprise resource. Both the subject endpoint and resource may be in compliance with enterprise security posture or expected to be in compliance after the session is completed. Service is located on-premises or as PaaS/SaaS (IaaS does not make sense as it is a service that is running in the cloud).
Demonstration: An enterprise service establishes a session with an endpoint to perform some administrative task, then closes the connection.
Purpose and Outcome: The enterprise can push administrative actions to enterprise endpoints in a secure manner.
Table 5 - Scenario G-5 Demonstrations
Demo ID |
Service Location |
Endpoint Location |
Endpoint Type |
Desired Outcome |
|
|---|---|---|---|---|---|
G-5.1 |
a |
On-Prem |
On-prem |
Ent-Owned |
Access Successful |
G-5.1 |
b |
On-Prem |
Branch |
Ent-Owned |
Access Successful |
G-5.1 |
c |
On-Prem |
Remote |
Ent-Owned |
Access Successful |
G-5.1 |
d |
On-Prem |
On-prem |
BYOD |
Access Successful |
G-5.1 |
e |
On-Prem |
Branch |
BYOD |
Access Successful |
G-5.1 |
f |
On-Prem |
Remote |
BYOD |
Access Successful |
G-5.1 |
g |
PaaS |
On-prem |
Ent-Owned |
Access Successful |
G-5.1 |
h |
PaaS |
Branch |
Ent-Owned |
Access Successful |
G-5.1 |
i |
PaaS |
Remote |
Ent-Owned |
Access Successful |
G-5.1 |
j |
PaaS |
On-prem |
BYOD |
Access Successful |
G-5.1 |
k |
PaaS |
Branch |
BYOD |
Access Successful |
G-5.1 |
l |
PaaS |
Remote |
BYOD |
Access Successful |
G-5.1 |
m |
SaaS |
On-prem |
Ent-Owned |
Access Successful |
G-5.1 |
n |
SaaS |
Branch |
Ent-Owned |
Access Successful |
G-5.1 |
o |
SaaS |
Remote |
Ent-Owned |
Access Successful |
G-5.1 |
p |
SaaS |
On-prem |
BYOD |
Access Successful |
G-5.1 |
q |
SaaS |
Branch |
BYOD |
Access Successful |
G-5.1 |
r |
SaaS |
Remote |
BYOD |
Access Successful |