Friday, October 29, 2021

Generating Secure Passwords: A C++ Example

 For some reason, that escapes me at the moment, I needed to generate a few passwords.  And having spent most of my career as a Software Engineer, I don't spend the time brainstorming those bits, I write a program.  Or perhaps better, I let someone else write the program. 

So I did: I found someone's work, which was broken, fixed it, improved it, and now I'm sharing it with you.

Enjoy.

https://github.com/W1T3H4T/password-gen

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





Thursday, February 13, 2020

The CPU as a BlackBox

The black boxes you trust for all of your computations are not secure. They have their own backdoors.
This is why we do defense in depth.  While configuring our systems to run only authenticated software may seem to be over-kill, it may soon be the only reasonable solution.

Investigate ways to enable your systems to execute signed and authenticated software only.

BlackHat 2018


This talk will demonstrate what everyone has long feared but never proven: there are hardware backdoors in some x86 processors, and they're buried deeper than we ever imagined possible. While this research specifically examines a third-party processor, we use this as a stepping stone to explore the feasibility of more widespread hardware backdoors.

BlackHat 2017

A processor is not a trusted black box for running code; on the contrary, modern x86 chips are packed full of secret instructions and hardware bugs. In this talk, we'll demonstrate how page fault analysis and some creative processor fuzzing can be used to exhaustively search the x86 instruction set and uncover the secrets buried in your chipset.

Wednesday, February 12, 2020

Password Policies in Finance

Developing a Password Policy

A password policy cannot be created in a vacuum, it must be derived from the Security Policy & Process of the Organization. Usually, this is called the ISMS, or Information Security Management System. In the general case, it will consist of a variety of policy documents addressing different aspects of information security.

For Banking and Payments, an ISMS will direct its Business Units to derive best practices from at least the following standards and regulatory artifacts:
  • PCI SSC – Payment Card Industry Security Standards Council
  • SOX – Sarbanes-Oxley Act
  • GLBA – Gramm-Leach-Bliley Act
  • … and potentially others.
Per PCI, SOX and GLBA requirements, your password needs will comply with these requirements:

PCI DSS

  • 2.1 – Never use vendor-supplied defaults
  • 2.3 – Encrypt all non-console administrative access using strong cryptography
  • 3.6.6 – If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.
  • 6.3.1 – Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
  • See Requirement 8: Identify and authenticate access to system components

SOX

Sarbanes-Oxley experts and auditors recommend that to meet the minimum for compliance, passwords should:
  • Be at least eight characters long;
  • Include a combination of letters and numbers;
  • Not contain personal information.

GLBA

Section 501 of the GLBA, “Protection of Nonpublic Personal Information,” requires financial institutions to establish appropriate standards related to the administrative, technical, and physical safeguards of customer records and information. The scope of these safeguards is defined in the GLBA Data Protection Rule, which states that financial institutions must:
  • Ensure the security and confidentiality of customer data
  • Protect against any reasonably anticipated threats or hazards to the security or integrity of such data
  • Protect against unauthorized access to, or use of, such data that would result in substantial harm or inconvenience to any customer.

Security Policies

When creating any kind of Security Policy, avoid the temptation to first consider assets, such as information systems consisting of infrastructure, applications, and operating systems. Instead, focus on the sensitive information that requires protection. 

A Security Policy can be understood as follows:

It is a high-level statement (plan or framework) addressing security requirements and objectives. It may address an entire organization or be specific to an issue or system.
It is a type of governance in that it expresses the security framework established by management. It is the primary method by which an organization sets expectations for a variety of topics.
  • The audience for the policy consists of architects, designers, implementers, installers, maintainers, and users of the Information the Organization needs to protect.
  • Policies can be written to affect hardware, software, access, people, connections, networks, telecommunications, enforcement, and so forth.
  • A good Security Policy cannot be drafted without a comprehensive understanding of the security standards that must be achieved.

Security Standards
While a Security Standard may be an internally developed, it is usually an external document authored by a regulatory organization (e.g., PCI SSC), or an organization tasked with developing best practices (e.g., NIST, ISO, ISACA).
  • A Security Standard is an enumeration of actions or rules that must be performed or followed to implement a Best Practice. E.g., NIST SP-800-53, ISO 27001, COBIT

Process

  • A Security Process defines a set of activities or related tasks that when combined, produce the desired result.

Procedures

  • Procedures are step-by-step instructions to perform various tasks in accordance with established Policy and Process.

Guidelines

  • Guidelines provide advice regarding how to achieve a goal of a Security Policy, or Process. They are a communication tool used to provide suggestions, they do not provide rules.

Developing an Information Security Policy

Data Identification and Scope

  • Identify sensitive information that must be protected;
  • Identify every location where sensitive information is scored;
  • Develop data classifications and tag data;
  • Determine in-scope information systems and out-of-scope information systems, tagging information systems appropriately;
  • Determine the approved ways in which data may be accessed.

Develop a Risk Management Framework

  • A Risk management framework helps you understand the risks associated with your information and how to manage those risks.
This is a key process to developing a password policy.

Establishing a risk assessment framework

  • Identify risks
  • Analyze risks
  • Evaluate risks
  • Select risk management options

Create the Risk Treatment Plan

  • This involves creating and managing security controls to mitigate and remediate risks.

Putting it together

Once you understand the data that must be protected, and the systems that process that data, the risks to which you are most commonly exposed, you can then begin developing requirements for Information Systems relevant to:
  • Regulatory requirements;
  • Data classification;
  • Best Practices;
  • User Experience & Acceptance

Thursday, November 14, 2019

The SDLC vs. An SDLC


Understanding how to implement the SDLC in your SDLC

In the 1960s, we developed a process called the System Development Life Cycle. In the 1990s and early 2000s, we began creating a process called the Security Development Life Cycle. Sometimes we shorten that to SDL (as in Lifecycle) but the intent is the same. In other instances, we emphasize only the development of secure software, incorrectly implementing a Secure Development Life Cycle.

In this post, I'm exploring the System Development and the Security Development life cycles. These process phases are not written in stone, but they do represent the general flow of development for a given information system. Your experience may vary.

The System Development Life Cycle

A product or system development life cycle generally consists of the following phases.

Initiation

In the initiation phase, product stakeholders develop concepts, business requirements and perform analysis. A requirements specification is developed. Executive approvals are generally obtained in this phase. 

Planning


In the planning phase, product stakeholders develop fundamental and architectural design constraints based on requirements. Primary use cases are developed.

Design


Information System designs are developed, less important implementation decisions are made using requirements documentation. Data classification and data dictionaries are developed. Use cases are refined and expanded.

Implementation


Coding begins and quality assurance designs (bug bars, quality gates) are specified and implemented. Minor design considerations are explored, tested and implemented. Components of the application are submitted for verification. 

Verification


Functional and non-functional testing is performed. The application may be pushed back into the implementation phase as components are tested. The product is moved towards production using one or more stages involving smoke testing, readiness testing, and a variety of reviews and approvals.

Release


The product is moved into production. The Product Team receives reports from consumers and concerned 3rd parties pertaining to features, bugs, and vulnerabilities. Based upon this information, the product lifecycle will restart in the Planning phase, ultimately resulting in major, minor, or patch releases.

Disposal


The product is decommissioned and potentially replaced with a different solution.

The Security Development Life Cycle & Alignment


The security development life cycle injects the system development life cycle with security best practices at each phase.


Initiation


Concepts and business requirements are reviewed for the application of customary security controls. General architectural security requirements are expressed and proposed.

Planning 


Architectural security requirements are reviewed, revised and established. Data flow diagrams are produced and threat modeling (e.g., STRIDE by element & interaction) is performed. Abuse cases are developed. General product security requirements are reviewed, revised and established.

Design 


Abuse cases are refined and developed. Product security requirements are reviewed and updated. Core components are reviewed for security requirements in alignment with architectural security requirements and industry best practice standards.

Implementation 


Product security requirements are implemented and built into the product; secure architecture design, abuse cases, and threat models instruct implementation. A variety of security testing is performed in conjunction with known attack vectors and threat actors. Test-driven development may be utilized; unit tests and security tools are developed and procured to exercise and expose the security qualities of the application.

Verification 


Additional security testing is performed for those things that cannot be easily confirmed with unit tests or test-driven development. Testing results are confirmed against abuse cases and product security requirements.

Release 


The information system is monitored for vulnerabilities in the applications, the operating systems, and the infrastructure. Observations are communicated to the product team. The PSIRT is engaged as necessary.

Disposal


Design documentation, data classification, and data dictionaries are reviewed. Plans are developed to retain or dispose of data in a secure manner.

Summary

The idea is to understand where key activities are taking place within the Development Life Cycle, so that we may insert the appropriate Security Development activities.  

Remember this key idea: just as Software Engineers develop applications using software and engineering best practices, Security Architects enable the development of Secure Qualities that can be traced to Security Standards and well-designed Product Security Requirements.