MINIMAL TECHNICAL CONTROLS STANDARD PROGRAM
TOPIC = BUSINESS CRITICAL REUSABLE TEMPLATES or SCRIPTS
This
document outlines the minimal technical controls for business critical reusable
template files or scripts. A reusable
template [RT] is defined as a separate file that defines a set of resources. RT’s
are intended to be reused across different deployments, which creates
consistency across complex deployments.
CONTROLS
ESCROW:
1. The RT, when approved must be stored in escrow. Priority will be given for storage in the
authoritative Network Hardware Storage Module (NET HSM).
a. If NET HSM storage is not technically
feasible an enterprise secure escrow repository will be implemented with
technical controls that satisfy PCI-DSS version 3.0 criteria at a minimum:
i.
Isolated
Virtual Local Area Network (V-LAN).
ii.
Encryption
of data at rest.
iii.
Anti-Malware
protection (For example: if the host OS utilizes McAfee, the repository should
implement Malware Bytes).
iv.
Physical
security and access control list protections.
v.
Logging,
monitoring and real time alerting.
vi.
Written
standards for Create, Read, Update and Delete operations [C.R.U.D.] must be put in place to control the RT’s
in escrow to ensure integrity.
RECURSIVE
DATA VALIDATION:
1. Using an automation, the RT checked
out of escrow must be compared to the
RT in escrow at run time.
a. This comparison must be logged and reported on on a recurring basis.
b. A separate account must be created to enable this
automation to ensure that the audit trail supports data integrity.
2. After modification and in accordance
with currently authoritative change management processes, the contents of the
RT must be verified to ensure that
nothing unauthorized has been added to the RT, for example, but not limited to:
a. Encryption Keys
b. Identity Tokens
c. USERID’s and/or Passwords
d. Other security context descriptors
e. Questionable content or sub-routines
AUTHENTICATION:
1. The security context of the requestor
may be evaluated at run time before
allowing RT’s to be checked out of escrow (are the credentials valid or
invalid?).
a. This is applicable to human and
non-human requestors.
b. Credentials for authentication can
take many forms as documented in NIST SP 800-36b, “Digital Identity Guidelines:
Authentication and Lifecycle Management”, section 4.1.1.
i.
Any
of these are acceptable.
c. Periodic re-authentication may take place at a time interval that
is indicative of the value or classification of the data being accessed /
protected.
2. Authentication credentials must be requested at run time from the
System of Record (SOR) for authentication via the consuming system.
3. If required, multi-factor authentication
[MFA] controls will be implemented to ensure a greater expectation of trust in
the identity of the requestor and ensure non-repudiation.
a. These controls will be based on the
authoritative MFA standard at the time.
4. Authentication events must be logged and reported on.
5. Digital Certificates used for mutual
authentication must be requested at
run time and never stored in the RT, portable mass storage device or system
file system(s).
a. Certificates used for authorization must be validated at run time against
the issuing Certificate Authority (CA) Certificate Revocation List (CRL).
6. Outbound cloud provider configuration
connection requests:
a. Must verify the IP address of the
requesting and requested host system and the security context of the requester
(human or non-human) before completing the connection request.
i.
Ensure
the IP reputation of the remote host prior to finalizing the connection.
b. That are not encrypted will be
rejected at the cloud provider perimeter or end point.
c. Must be logged and reported on.
AUTHORIZATION:
1. Authorization requests:
a. Must be evaluated in a standard manner.
b. Authorization logic must be protected and escrowed to ensure
integrity.
c. Must follow a standard: Policy
Enforcement Point [PEP]; Policy Decision Point [PDP]; Policy Information Point
[PIP] architecture.
iii.
Attribute Based Access Control: NIST SP 800-162.
LOGGING REQUIREMENTS:
1. Requests for AUTHENTICATION and
AUTHORIZATION
a. Successful and un-successful
b. From the System of Record [SOR].
2. Requests from the Escrow Repository
a. Successful and un-successful
3. Exception handling
a. Successful and un-successful
b. Calls back to sending system if
validation is negative
4. Specifically
a. Connection requests to and from cloud
vendors
GOVERNANCE:
Controls in
this document are extracted from:
1. Cloud Security Alliance, “Security
Guidance for Critical Areas of Focus in Cloud Computing”, v4.0
RACI Matrix
Minimal technical Controls for Cloud Deployment Scripts
[1]
https://cloudsecurityalliance.org/artifacts/security-guidance-v4/
[2]
https://www.nist.gov/publications/nist-cloud-computing-reference-architecture
[3]
https://cloudsecurityalliance.org/research/working-groups/cloud-controls-matrix
[4]
https://csrc.nist.gov/publications/detail/sp/800-207/draft
[5] https://www.nist.gov/cyberframework
[6] IT SERVICE MANAGEMENT RACI MATRIX: https://advisera.com/20000academy/blog/2016/01/12/itil-iso-20000-raci-matrix-how-to-use-it-to-clarify-responsibilities/
