Establish security based on SLSA (Supply chain Levels for Software Artifacts) DevSecOps standards and controls.
Overview
This article defines the sequence of threats and what can be practically done about them.
Actions defined to establish security controls for software artifacts, at each of 4 levels of maturity:
A. To limit the submission of unauthorized changes into GitHub repositories, enforce practices defined in my example CONTRIBUTING article:
-
A1. all changes be submitted through pull requests (PRs) and
A2. PRs be reviewed and approved by at least one other person before being merged into the main branch.
B. To limit compromise of GitHub accounts, enforce:
-
B1. MFA (Multi-Factor Authentication) for all logins (vendor: Microsoft Entra ID P2).
B2. Limit posting of emails and other sensitive information in GitHub profiles, issues, PRs, etc.
B3. Require the strongest TLS level to communicate (to prevent man-in-the-middle attacks).
C. To limit build from modified source:
-
C1. Assign least privilege permissions to limit each user account to the minimum permissions needed to do their job.
C2. Segment builds into zones so each team is focused on their own content. This limits lateral movement by attackers.
D. To limit compromised dependencies:
-
D1. Create a SBOM (Software Bill of Materials) of each open-source library package down the chain of references.(Vendor: Artifactory XRay).
D2. In each dependency in the SBOM, raise an alert if a CVE has been reported for the package. (Vendor: GithHub Dependabot, Snyk, Sonatype, WhiteSource, BlackDuck, Synopsys, Veracode, Checkmarx, Contrast Security, Fortify, Qualys, Rapid7, RiskSense, Tenable, Trustwave, WhiteHat Security, ZeroNorth, etc.)
D3. Scan the code of each package for vulnerabilities such as exfiltrating data externally. (Vendor: socket.dev)
E. To limit use of compromised dependencies:
-
E1. After each install, create a hash of each static (executable) file, then generate them repeatedly on a schedule to see if they have been changed to a potentially hacked version. File integrity host-based IDPS (Intrusion Detection and Protection System) Vendor: Atomic OSSEC, Solarwinds, Tripwire
F. To limit uploads of modified packages:
-
F1. After uploading a file, recalculate a hash of the file and compare it to the hash of the same file before it was uploaded. Raise an alert if the hashes are different.
G. To limit compromise package repositories:
-
G1. Limit permission to backup media to separate accounts so they can't be deleted and encrypted for ransomware.
G2. Segment the network into zones, with a firewall between each zone, and only allow the minimum ports and protocols needed for each zone. This limits lateral movement by attackers.
G3. Perform regular data backups to cloud storage to ensure data recovery.
G4. Verify recovery to prove the ability to recover from backups and reinstalls.
H. To limit the use of compromised packages:
-
H1. Reference packages from a private repository housing packages downloaded from the public (Vendor: Artifactory, Quay, Nexus, etc.)
H2. Reference packages based on its hash (Vendor: Artifactory, Quay, Nexus, etc.)
H3. Configure each device based on security recommendations in its CIS Benchmark.
H4. Verify that each device is running the latest version of patches of OS, utilities, apps.
H4. Automate installs of the latest version of every component (OS, utilities, apps) on laptops and servers in case of infection. This include drivers, firmware, TLS version, etc.
H5. Send alerts to SIEM (Security Information and Event Management system) upon irregular logins, when a device is added to or removed from the network, when data streams are larger or smaller than normal, etc. (Vendor: Microsoft Defender, Prometheus Cloud)
H6. Regularly schedule a fake test attack sent to each device, to ensure that alerts works in SIEM.
H7. Detect anomalies in network traffic, such as a sudden increase in the number of connections to a server, connection from unusual users, or a sudden increase in the number of bytes sent to a server.
API & OT (Operational Technology) Security
Standards for ICS (Industrial Control Systems) are defined by NIST (National Institute of Standards and Technology) as ISA/IEC-62443 or ISA-99 in the US and IEC (International Electrotechnical Commission) in Europe.
I1. Configure every node with certificates for two-way encryption using mTLS (Mutual TLS) between every node for all network connections.
I2. Have API servers verify JWT (JSON Web Tokens) signatures to block attempts at user impersonation. Sign JWT tokens with a private key, then verify the signature with a public key.
I3. Enforce a strict whitelist of permitted hosts for the jku header.
I4. Always set an expiration date for any tokens issued.
I5. Avoid sending tokens in URL parameter string, which end up in logs.
I6. Include the aud (audience) claim (or similar) to specify the intended recipient of the token. This prevents it from being used on different websites.
I7. Enable the issuing server to revoke tokens (on logout, for example).
I8. Setup secure video surveillance of remote hardware devices to provide a history of accesses.
I9. Use API management servers to assign API tokens so that the number of API calls per minute can be tracked and limited.
I10. Setup authentication and encryption for using SNMPv3 (Simple Network Management Protocol) to monitor devices. (Vendor: NetGuardian includes a RADIUS server which uses CBC-DES (Cipher Block Chaining Data Encryption Standard) as the default encryption algorithm, a part of the Universal Security Model (USM).)
SLSA Levels
The SLSA defines requirements to establish security controls for software artifacts, at each of 4 levels of maturity:
Level 0 - Unsigned provenance provides no guarantees of resilence against tampering.
Level 1 - A Scripted/automated build process generates provenance (metadata about how an artifact was built, including the build process, top-level source, and dependencies). This does not protect against tampering, but offers a basic level of code source identification and can aid in vulnerability management.
Level 2 - Version control in a host and a hosted build service (such as GitHub) that generates authenticated provenance, such as the use of hashes in a DAG (Directed Ascyclic Graph). This gives software consumers confidence in the origin of the software. At this level, the provenance prevents tampering to the extent that the build service is trusted.
Level 3 - The source and build platforms guarantee the auditability of the source and the integrity of the provenance to provide much stronger protections against tampering than earlier levels by threats such as cross-build contamination.
Level 4 - Two-person review of changes for catching mistakes and deterring bad behavior, such as procedures defined in this CONTRIBUTING doc. A hermetic, reproducible build process to guarantee that the SBOM dependencies is complete. Reproducible builds provide many auditability and reliability benefits. This gives the consumer a high degree of confidence that the software has not been tampered with.
PROTIP: To reduce arguments about priorities, pre-define this priority map (from red to orange, yellow, green, and gray) by focusing on the combination of impact and probability of each occurring:
The framework provides a way to rank the severity of each threat and to prioritize the actions to take to mitigate each threat.
PROTIP: Define the meaning of words for Impact Category Levels, such as this because values change over time (due to inflation, sales growth) and to provide a common vocabulary:
More on Security
This is one of a series on Security and DevSecOps:
- Security actions for teamwork and SLSA
- Code Signing on macOS
- Git Signing
- GitHub Data Security
- Azure Security-focus Cloud Onramp
- AWS Onboarding
- AWS Security (certification exam)
- AWS IAM (Identity and Access Management)
- SIEM (Security Information and Event Management)
- Intrusion Detection Systems (Goolge/Palo Alto)
- SOC2
- FedRAMP
-
CAIQ (Consensus Assessment Initiative Questionnaire) by cloud vendors
- AKeyless cloud vault
- Hashicorp Vault
- Hashicorp Terraform
- SonarQube
- WebGoat known insecure PHP app and vulnerability scanners
- Security certifications
- Quantum Supremecy can break encryption in minutes
- Pen Testing
- Threat Modeling
- WebGoat (deliberately insecure Java app)