...Drawing a Line in the Sand - Part One - Scripting Controls

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.

                                                              i.      https://en.wikipedia.org/wiki/Attribute-based_access_control

                                                            ii.      https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

                                                           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

2.    NIST, “Cloud Computing Reference Architecture”

3.    Cloud Security Alliance, Controls Matrix

4.    NIST, Zero Trust Architecture

5.    NIST, Cyber Security Framework

6.    AXELOS, IT Service Management Framework, v3  

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/