Thursday, September 2, 2021

Separation of Duties: Do not cross the Production and Test Streams

Here's a quick reference for justifying why an organization should never mix development, test, and production configurations and data.
 

PCI DSS 3.2.1

    • 6.4 – Follow change control processes and procedures for all changes to system components.  The process must include the following:
      • Development/test environments are separate from production environments with access control in place to enforce separation.
      • A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.
      • Production data (live PANs) are not used for testing or development.
    • 6.4.1 – Separate development/test environments from production environments, and enforce the separation with access controls.
      • Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s).
      • Examine access controls settings to verify that access controls are in place to enforce separation between the development/test environments and the production environment(s).
    • 6.4.2 Separation of duties between development/test and production environments
      • Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment.
    • 6.4.3 – Production data (live PANs) are not used for testing or development
      • Observe testing processes and interview personnel to verify procedures are in place to ensure production data (live PANs) are not used for testing or development.
      • Examine a sample of test data to verify production data (live PANs) is not used for testing or development.

National Institute of Standards and Technology (NIST)

    • Cybersecurity Framework Version 1.1

International Organization for Standardization (ISO)

    • https://www.unifiedcompliance.com/products/search-controls/control/6088/
      • Testing of releases shall be conducted in a controlled acceptance test environment. (§ 9.3 ¶ 4, ISO 20000-1, Information Technology - Service Management - Part 1: Service Management System Requirements, Second Edition)
      • Development, testing, and operational environments shall be separated to reduce the risks of unauthorized access or changes to the operational environment. (A.12.1.4 Control, ISO 27001:2013, Information Technology - Security Techniques - Information Security Management Systems - Requirements, 2013)
      • The development, test, and operational systems should be separated to reduce the chance of unauthorized modification to the operational system. The test system should emulate the operational as closely as possible. (§ 10.1.4, § 12.5.1, ISO 27002 Code of practice for information security management, 2005)

 Center of Internet Security (CIS)


Wednesday, February 24, 2021

CSPRNG: A Linux One-Liner

tl;dr






What is a CSPRNG?  

A CSPRNG is a Cryptographically Secure Pseudo Random Number Generator.  It is the cousin of the RNG, or Random Number Generator that we used decades ago.

In the past, rand and seed were used together to generate pseudo random numbers.  When a constant seed is provided (e.g., the number 125), the random numbers generated by rand are well-defined.  

These two functions actually complement each other well in fuzz-testing applications, since the sequence of randomness can be reproduced between invocations of the tool.

However, there's a problem: these functions are not viable for creating key material.  In cryptography, well-formed randomness is required.  As such, rand and seed are not candidates for generating key material.  What is needed is a source of randomness that mimics the real world: such as the path a leaf takes when falling to the ground.

In the cryptography discipline, CSPRNGs are used to generate private and public key material, such as those used for certificates, secure shell sessions, and cryptocurrency. 

Can I generate my own CSPRNG on Linux, using a shell?


Yes.  It turns that on Linux, it's a very easy task.

Every (or almost every) recent Linux implementation generates random data that can be accessed through /dev/random, /dev/arandom, and /dev/urandom.  There are differences between these implementations that you should be aware of when selecting them for any variety of solutions.  See here for more information: /dev/random vs /dev/urandom and are they secure?

For this example, we will use /dev/urandom.

The easiest method of obtaining random data is via cat.  We'll follow that by extracting a set number of bits, reformatting the data, and delivering a string of hexadecimal digits. 

The One-Liner:

cat /dev/urandom | head -c 2048| od -x | cut -b 8-40 | xargs | sed 's/ //g' | head -c 32


In this script, we grab 2048 characters of data (16384 bits), convert them to hexadecimal using od, and then grab the hex digits using cut, while removing the line-feeds.  We remove the spaces created by od, and then select a string of 32 bytes, which is 256 bits (32 x 8 == 256).

If you want a bit more sophistication, then here's a full script:


#!/bin/bash
#   =================================================================
#   File    :   csprng.sh
#   Function:   Generate a cryptographically secure random number
#   Who     :   David Means <www.w1t3h4t.com>
#   =================================================================

function doHelp()
{
    echo
    echo "Generate a cryptographically secure random number"
    echo
    echo "Usage: $(basename $0) {bits}"
    echo
    echo "Example: $(basename $0) 128"
}

if [ $# -eq 0 ] ; then
    doHelp
    exit
fi

bytes=0
bitCheck=$(($1 % 8))

if [ $bitCheck -eq 0 ]; then
    bytes=$(($1 / 8))
     cat /dev/urandom | head -c 2048 | od -x | cut -b 8-40 | xargs | sed 's/ //g' | head -c ${bytes}
     echo
else
    echo 
    echo "$1 not divisable by 8"
    echo
fi