AllDayDevOps 2017: Continuous Patch and Security Assessment with InSpec

Best-practices for server hardening and patching have been in place for decades. Nevertheless, it is still very cumbersome to enforce those rules continuously and many servers are still unsecured in 2016. DevOps tools like Chef, Puppet or Ansible help to enforce secure configuration, but they cannot fully assess a state of a machine e.g. you cannot easily verify if something is not installed. InSpec is here to help. It is an open source tool for infrastructure, security and compliance testing. InSpec’s DSL is a human and machine-readable assessment language that is extendable and customizable. Since testing can be fully automated with InSpec, companies are enabled to assess and enforce secure configuration across their IT fleet. Integration with CI/CD systems allows continuous testing in high-velocity organizations. This talk will give an introduction to InSpec and demonstrate how patch and security level can be assessed in CI/CD and production environments.

Transcript

1. Continuous Patch and Security Assessment with InSpec Christoph Hartmann Lead Engineer Chef Software @chri_hartmann
2. @chri_hartmann $> whoami Christoph Hartmann • Engineering Lead at Chef Software • Co-Founded Dev-Sec.io project • Co-Founder of VulcanoSec • Acquired by Chef Software • InSpec Creator chris-rock
3. InSpec turns infrastructure testing, compliance and security requirements into code
4. Agenda Compliance DevOps
5. Challenges in Production #1
6. The tip of the iceberg Heartbleed Shellshock WannaCry Cyber-Threat landscape
7. 73% Financially motivated 51% Organized Criminal Groups 75% External attacker Verizon Data Breach Report 2017 The tip of the iceberg Cyber-Threat landscape
8. State of Security in 2014 • In 60% of cases, attackers can compromise organizations within minutes. • 99.9% of the exploited vulnerabilities were compromised more than a year after the vulnerability was published. • Ten vulnerabilities account for 97% of the exploits observed. Verizon Data Breach Report
9. OWASP Top 10
10. A5 – Security Misconfiguration Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, platform, etc. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date. A9 – Using Components with Known Vulnerabilities Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. OWASP Top 10
11. Source: http://content.time.com/time/covers/europe/0,16641,20020708,00.html
14. Regulatory Compliance PCI-DSS Gramm-Leach-Bliley Act HIPAA Dodd-Frank ISO Sarbanes-Oxley HITECH Grundschutz European Central Bank Regulations
15. Reporting of compliance activity is extensive EY – A time of evolution for compliance: laying foundations for future success
16. Huge scope remains for tapping into the power of technology EY – A time of evolution for compliance: laying foundations for future success
17. COMPLIANCE AND SECURITY Compliance Security
18. Let’s Automate #2
21. github.com/dev-sec
23. Scale
24. Scale
25. Scale
28. Agenda Compliance DevOps
29. Wait! #3
31. Drivers for Compliance Security Reduce risk and protect business Liability Avoid negligence
33. Language Compliance DevOps Security
34. Compliance-Driven Infrastructure #4
35. Tradeoff: Speed vs Risk DevOps teams focus on faster innovation, potentially increasing risk InfoSec teams focus on mitigating risk, potentially reducing speed
36. QUALITY/COMPLIANCE RATE OF INNOVATION Scale Speed and Compliance
37. Detect Correct Compliance Continuous
38. Let’s talk about solutions github.com/dev-sec
39. Works with all DevOps tools e.g.
40. InSpec turns infrastructure testing, compliance and security requirements into code
41. Surface check #1: Know your security stance
42. Surface check Deep analysis #1: Know your security stance
43. • Operating Systems • DBs, AppServers • Apps • On-prem, Cloud, Hybrid, Containers Deep analysis #1: Know your security stance
44. Faulty assumptions #1: Know your security stance
45. Faulty assumptions #1: Know your security stance
46. • Prevent insecure production env. • Report and alert continuously • Provide proof Faulty assumptions #1: Know your security stance
47. Documentation SSH supports two different protocol versions. The original version, SSHv1, was subject to a number of security issues. Please use SSHv2 instead to avoid these.
48. Scripting tools
49. The better way TESTING A REQUIREMENT
50. Standalone Usage $ inspec exec test.rb $ inspec exec test.rb -i vagrant.key -t ssh://root@172.17.0.1:11022 $ inspec exec test.rb -t winrm://Admin@192.168.1.2 --password super $ inspec exec test.rb -t docker://3cc8837bb6a8 describe sshd_config do its('Protocol') { should cmp 2 } end
51. Mapping of Compliance Document to InSpec
52. Compliance Language
53. apache apache_conf apt audit_policy auditd_conf auditd_rules bash bond bridge bsd_service command crontab csv dh_params directory docker docker_container docker_image etc_group file gem group groups grub_conf host http iis_site iis_website inetd_conf ini interface iptables json kernel_module kernel_parameter key_rsa launchd_service limits_conf login_defs mount mssql_session mysql mysql_conf mysql_session npm ntp_conf oneget oracledb_session os os_env package packages parse_config parse_config_file passwd pip port postgres postgres_conf postgres_session powershell ppa processes rabbitmq_config registry_key runit_service script security_policy service shadow ssh_config sshd_config ssl sys_info systemd_service sysv_service upstart_service user users vbscript windows_feature windows_registry_key windows_task wmi x509_certificate xinetd_conf yaml yum yumrepo zfs_dataset zfs_pool Built-in resources
54. Supported Operating Systems
55. InSpec Profiles Folder Structure
56. InSpec Profiles inspec.yml
57. $ inspec supermarket profiles == Available profiles: * apache2-compliance-test-tthompson thompsontelmate/apache2- compliance-test-tthompson * Apache DISA STIG som3guy/apache-disa-stig * chef-alfresco-inspec-mysql alfresco/chef-alfresco-inspec-mysql * chef-alfresco-inspec-tomcat alfresco/chef-alfresco-inspec-tomcat * chef-client-hardening sliim/chef-client-hardening * CIS Docker Benchmark dev-sec/cis-docker-benchmark * CVE-2016-5195 ndobson/cve-2016-5195 * DevSec Apache Baseline dev-sec/apache-baseline InSpec Supermarket
58. github.com/dev-sec
59. DevSec InSpec Profiles Operating Systems DevSec Linux Baseline DevSec Linux Patch Baseline DevSec Windows Baseline DevSec Windows Patch Baseline DevSec SSH Baseline DevSec SSL/TLS Baseline CIS Distribution Independent Applications DevSec Nginx Baseline DevSec MySQL Baseline DevSec PHP baseline DevSec Apache Baseline DevSec PostgreSQL Baseline Application Runtimes DevSec OpenStack Baseline CIS Docker Benchmark CIS Kubernetes Benchmark
60. Linux Patch Benchmark Acme Inc include_controls ’linux-patch baseline’ depends: - name: linux-patch baseline InSpec Profile Management
61. Manage Baselines My CIS L1 (inspec overlay) CIS Lvl1 (xml base profile)
62. Manage Baseline Overlays Dev Production Test My CIS L1 (inspec overlay) CIS Lvl1 (xml base profile)
63. InSpec Profiles github.com/dev-sec DevSec Windows Patch Baseline DevSec Linux Baseline DevSec Windows Baseline DevSec Linux Patch Baseline
64. InSpec Profiles github.com/dev-sec github.com/chris-rock/acme-inspec-profile DevSec Windows Patch Baseline DevSec Linux Baseline DevSec Windows Baseline DevSec Linux Patch Baseline
65. InSpec Profiles DevSec Windows Patch Baseline DevSec Linux Baseline DevSec Windows Baseline DevSec Linux Patch Baseline github.com/dev-sec github.com/chris-rock/acme-inspec-profile
66. InSpec Profiles
67. Continuous Compliance Compliance DevOps
68. Continuous Compliance Scan for Compliance Build & Test Locally Build & Test CI/CD Remediate Verify
69. Outlook #4
70. 225 releases (once a week) 19 days Issue resolution time 137 Contributors 880 Stars InSpec Project Health
71. Infrastructure
72. chef/inspec-vmware chef/inspec-azure chef/inspec-aws InSpec for Platforms
73. describe aws_iam_user(’iam_user') do its('has_mfa_enabled?') { should be false } its('has_console_password?') { should be false } end InSpec for AWS
74. describe azure_virtual_machine(name: 'Linux- Internal-VM', resource_group: 'Inspec-Azure') do its('sku') { should eq '16.04.0-LTS' } its('publisher') { should eq 'Canonical' } its('offer') { should eq 'UbuntuServer' } its('size') { should eq 'Standard_DS2_v2' } its('location') { should eq 'westeurope' } its('admin_username') { should eq 'azure' } end InSpec for Azure
75. control 'vmware-7.3.3' do impact 0.7 title 'Ensure that the vSwitch Promiscuous Mode policy is set to reject.' describe vmhost_vswitch(datacenter: 'vm001', host: 'localhost.localdomain',vswitch: 'vSwitch0') do its('allowPromiscuous') { should be false } end end InSpec for VmWare
76. Further Resources inspec.io • Hands on tutorials • Extensive documentation • Code examples dev-sec.io • github.com/dev-sec/linux-baseline • github.com/dev-sec/windows-baseline • github.com/dev-sec/windows-patch-baseline • github.com/dev-sec/linux-patch-baseline
77. Join github.com/chef/inspec
78. Session Title Your Name Your Title Your Company Your @TwitterHandle
79. Session Title Your Name Your Title Your Company Your @TwitterHandle
80. @chri_hartmann Christoph Hartmann chartmann@chef.io
81. bit.ly/addo-slack Find me on slack, right now!