Download to read offline
OSC2023_security_automation_data.pdf
- 1. Security Automation Data supplychain security lost in a maze of XML and JSON Marcus Meissner Projectmanager Security / Distinguished Engineer meissner@suse.de
- 2. 2 Agenda ● Introduction ● The SCAP family ● Newcomers ● Newthings and changes past Solarwinds and log4shell
- 3.
- 4. 6 Introduction – Why? •Amount of computers growing – Hard to even enumerate the ones at home • Laptop, tablet, phones, tv, car, cameras, toys, home automation, etc. – Enterprise setting • Baremetal / Edge • VMs • Containers • Public Cloud instances • Amount of care needed differs, depends: – How much access / control do we have – Managed by us or by others … or no one – Internet connected / Importance / relevance
- 5. 7 Inventory Without Inventory weare blind • Hardware (not in scope here) • Operating System • Software installed • Configurations and Settings… • Recursion into Vms or Containers
- 6. 8 Operating System /Software Interesting pieces about software • Lifecycle • Affectedness by security issues • Recursion for embedded sources • Recursion for static builds (e.g. builds with go, rust etc) • Dependency on build environment • How to proof or verify this is correct Manual work impossible, automate everything!
- 7. 9 The SCAP family SecureContent Automation Protocol
- 8. 10 Secure Content AutomationProtocol - SCAP One of the early comers, defined by the US NIST Encompasses formats: • OVAL, XCCDF, OCIL, ARF, CCE, CPE, CVE, CVSS, CCSS Standard Version: 1.3 Supporting tool: openscap
- 9. 11 CVE – CommonVulnerability & Exposures Goal: A dictionary entry identifying a specific security vulnerability. CVE-Year-NR • Year is the time the security issue was identified. • NR is allocated out of non-linear blocks (no specific meaning) Assigned by CNAs (Candidate Naming Authorities). When use, make sure you copy and paste only to avoid typos!
- 10. 12 CVSS - CommonVulnerability Scoring System Goal: Trying to classify security vulnerabilities into schemes and numbers. • Base Vector, Temporal Vector, Environmental Vector • Sample Base Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H • Score: 0.0-10.0 (above is 7.8) Currently at revision 3.1, revision 4 being worked on. Facts: • As security issues are programmatic, translation into a simple arithmetic vector is hard • Not all criteria map well • There is a lot of human judgment involved, rating might vary
- 11. 13 CPE – CommonPlatform Enumeration Goal: Specify operating systems and/or software in a defined way. Standardized hierarchic tag format: • cpe : ID : vendor : product : version : minor version … Idea is that you can synthesize it yourself, but there is a global dictionary. Examples used by SUSE: • cpe:/o:suse:sles:15:sp4 ( in /etc/os-release ) • cpe:/o:opensuse:tumbleweed:20230510 • cpe:2.3:a:samba:samba:*:*:*:*:*:*:*:* (in some other security data) Not very widespread, also replaced by other formats like purl.
- 12. 14 CCE – CommonConfiguration Enumeration Goal: Dictionary to reference configuration issues IDs handed out by NIST to vendors. Used in hardening automation.
- 13. 15 CCSS – CommonConfiguration Scoring System Goal: Measure severity of configuration mismatches So /etc/shadow world-readable is higher than “telnet client” installed. Used in the hardening tooling.
- 14. 16 OCIL – OpenChecklist Interactive Language Goal: Allow automation of manual security checklist processing Going over the checklist is automated. The tests and remediations for each check are manual actions. Not used at SUSE.
- 15. 17 OVAL – OpenVulnerability Assessment Language Goal: Detection of system conditions Uses: CVE, CPE, CVSS ids Checks for: • Presence, permission, ownership of files • Content of files (line based) • RPM – presence , name , version , release based detection • More Definitions that describe vulnerabilities, patches, inventory • Metadata like description, references, cpe ids, cvss scores • Link to checks via a tree of criteria that can be combined with OR/AND logic
- 16. 18 OVAL – OpenVulnerability Assessment Language Example available logic: System is affected by a CVE when: • product X OR product Y is installed • AND – Package P1 is less than version1-release1, OR – Package P2 is less than version2-release2 /etc/shadow has insecure permissions: • File permission of /etc/shadow is not MODE 640, OR • File ownership of /etc/shadow is not USER root, OR • Group ownership of /etc/shadow is not GROUP shadow
- 17. 19 OVAL – OpenVulnerability Assessment Language SUSE usage: Provide security vulnerability data • Indexed by CVE • Indexed by patches • For released updates, but also for “not affected” or “affected” issues, or “in QA”. • Sample call: oscap oval eval suse.linux.enterprise.15.xml Detection logic for XCCDF in scap-security-guide
- 18. 20 XCCDF – eXtensibleConfiguration and Definition Format Goal: provide flexible security hardening automation References: OVAL, CCE, CCSS Invented to automate security hardening with STIG as example • High level Profiles, specify rules to enable • Rules – Metadata: description, identifiers (CCE, etc.), priority, rationales – Detection (references to OVAL definitions or also detection shell scripts) – Remediation (can be manual, shellscript, ansible … )
- 19. 21 SCAP - ComplianceAsCode XCCDFand OVAL are heavily nested XML, manual editing hard. Red Hat and others invented a generator framework called “ComplianceAsCode” which can generate various formats out its tree. SUSE is developing their own SCAP profiles together with the ComplianceAsCode community. Shipped in “scap-security-guide” package.
- 20. 22 SCAP – scap-security-guideSUSE usage SUSE provides SCAP implementations for • DISA STIG • PCI-DSS • HIPAA • CIS • ANSSI-BP-028 • SUSE specific hardening for public cloud images
- 21.
- 22. 24 CVRF – CommonVulnerability Reporting Format Goal: machine readable advisories and vulnerability exchange Version: 1.2 (obsoleted by CSAF) Format: XML References: CVE, CVSS, CPE Invented to automate security vulnerability exchange • Express security advisories in standard format • Automated detection of vulnerabilities • Import to ticket systems No logic like OVAL, but a hierarchical software component tree
- 23. 25 CVRF – CommonVulnerability Reporting Format SUSE Usage • CVRF by advisory id – Can report fixed security issues by the advisory • CVRF by CVE – Can report: affected, not affected, released, in qa Disadvantage: lots of files (1 file per patch or CVE)
- 24. 26 CSAF – CommonSecurity Advisory Format Goal: machine readable advisories and vulnerability exchange Version: 2.0 (replaces CVRF) Format: JSON References: CVE, CVSS, CPE Automate security vulnerability exchange • Express security advisories in standard format • Automated detection of vulnerabilities • Import to ticket systems Again a hierarchical software component tree
- 25. 27 CSAF – CommonSecurity Advisory Format SUSE Usage • CSAF by advisory id – Can report fixed security issues by the advisory • CSAF by CVE – Can report: affected, not affected, released, in qa Disadvantage: lots of files (1 file per patch or CVE)
- 26. 28 New things andchanges in recent years
- 27. 29 What changed? • Softwarebecoming more interlinked and more complex • Attacks becoming more direct / more impactful – Not just smuggling out information – Destructive / distributed denial of service – Ransom – whole companies – Make money out of crypto mining • Exploits targeting the software supply chain to be more widespread Solarwinds and log4shell as key triggers
- 28. 30 What changed? • Peopleand Governments identified software supply chain security as having gaps and reacted on it • US government issued Executive Order 14028 May 12th 2021 • Europe is working on a cyber resilience act Gaps covered: • Software Bill of Materials (SBOM) • Attestation or provenance of build (SLSA attestation) • Cryptographic assurances
- 29. 31 SBOM – SoftwareBill of Materials Goal: Clear inventory of Software Deliveries Wanted: structured export of • Producers and redistributors/suppliers • Exact versions, licenses • Software embedded in other software • Cryptographic hashes / verification Three main file formats currently: • SPDX 2.0 • CycloneDX • SWID
- 30. 32 SBOM – SUSEDeliveries Formats: • SPDX 2.0 (prefered by the LinuxFoundation) • CycloneDX (widespread use in the container ecosystem) Delivered for: • ISO: SPDX 2.0 and CycloneDX • Containers: SPDX 2.0 embedded in SLSA attestation
- 31. 33 SBOM – SPDX2.0 Originally SPDX was for standardized license tracking. Enhanced to support full SBOM for 2.0 version. Fileformats: various: plaintext, XML, JSON, … SUSE uses JSON variant.
- 32. 34 SBOM – CycloneDX Fileformats:XML or JSON CycloneDX can not just cover SBOM, but also • Saas BOM • HW BOM • Operations BOM • Vulnerability Disclosure Reports (VDR) • Vulnerability Exploitability eXchange (VEX)
- 33. 35 VEX – VulnerabilityExploitability eXchange Goal: Declare affected or not affected for security issues Existing: • CVRF: CVE indexed format would qualify • CSAF (has a VEX profile): ready Others: • CycloneDX • OpenVEX project (picked up by OSSF)
- 34. 36 VDR – VulnerabilityDisclosure Report Goal: Declare affected or not affected of a product Supplements an SBOM. Currently not clear what is needed here.
- 35. 37 Attestation and Provenance Goal:define how software was built into binary Why: defined description how a binary was built, reproducibility Primary contender: • SLSA attestation “in-toto”
- 36. 38 SLSA In-toto provenance Specifyevery package this target was built with • RPMs listed with URLs and SHA2 hashes (rpms provided externally) • Buildconfiguration linked (OBS projectconfig) with SHA2 • Sources within package linked and referenced with SHA2 Provenance provided parallel to built RPM, ISO, Container. Challenges: • Rolling releases (how many Terabyte diskspace do you own?) • Bootstrapping (where do you start?)
- 37. 80 Landing page: https://www.suse.com/security/ E-Mail:security@suse.de Questions?
- 38.
- 39.
- 41.
- 42. Presentation Title(36pt) Subhead orSecond Line (20pt) Presenter Name (14pt) Title Company/Email For Internal Use Only