Using Chef InSpec for Infrastructure Security
•Descargar como PPTX, PDF•
2 recomendaciones•2,005 vistas
How Chef InSpec helps your team keep tabs on your security and compliance requirements.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Using Chef InSpec for Infrastructure Security
Similar a Using Chef InSpec for Infrastructure Security (20)
Más de Mandi Walls
Más de Mandi Walls (17)
Último
Último (20)
Using Chef InSpec for Infrastructure Security
- 1. Seattle | September 16-17, 2019 Infrastructure Security Assurance with Chef InSpec MANDI WALLS
- 2. HI! • Mandi Walls • Developer Advocate at Chef • mandi@chef.io • @lnxchk • https://www.chef.io/ • https://www.inspec.io/
- 3. EVERY business is a software business We’re going to be a software company with airplanes. – CIO, Alaska Airlines
- 6. Different Sources for the Same Goals
- 8. Chef InSpec • Human-readable language for tests related to security and compliance • Create, share, and reuse complex profiles • Extensible language - build your own rules • Command-line tools plug into your existing workflow, build, deploy • Test early, test often!
- 9. Create and Consume • Complex compliance requirements can slow you down • Different information and expertise live in different teams, but need to be used by many • Security and compliance personnel can work with operations and development to create comprehensive profiles
- 10. Chef InSpec is Code • Check it into repos, publish as artifacts • Include InSpec steps before code checkin • Include InSpec steps in integration and pre-production • Continue InSpec checks in production to guard against new threats
- 11. Network Services • If your security team sends you a directive: Ensure that no legacy network services are installed on all versions of Linux, including inetd, xinetd, telnet, rsh, tftp, and ypserv.
- 12. How Do You Go About Checking and Fixing? • Identify the package names on your systems • Remove all packages • What’s the plan for the currently used images? Rebuild for new images? Remediate at launch and hope nothing gets in before the updates? • Ensure it doesn't get re-installed by accident at some point in the future
- 13. Check for inetd and xinetd control 'package-01' do impact 1.0 title 'Do not run deprecated inetd or xinetd' desc 'rhel5-guide-i731.pdf, Chapter 3.2.1' describe package('inetd') do it { should_not be_installed } end describe package('xinetd') do it { should_not be_installed } end end
- 14. Chef InSpec Components • Resources • Resource Characteristics • Profiles • Command Line Interface
- 15. Resources • Chef InSpec includes built-in resources for common services, system files, and configurations • Built-in resources work on several platforms of Linux. There are also Windows-specifics like registry_key • A resource has characteristics that can be verified for your requirements, and Matchers that work with those characteristics
- 16. Sample Resources • System resources: directory, file, user, group, crontab, service, package • Specific services: apache, nginx, rabbitmq, postgresql, IIS • Programming language components: gem, npm, powershell • Network services: port, http, sshd • https://www.inspec.io/docs/reference/resources/
- 17. Characteristic Tests • it { should exist } – files, directories, groups that are present • it { should be_installed } – packages that should be installed • it { should be_enabled } – services that should be running • its('max_log_file') { should cmp 6 } – rotate auditd logs Check inside a config file for a specific setting • its('exit_status') { should eq 0 } – run any arbitrary checks Remediation scripts from upstream and OS vendors often come as shell
- 18. Run Chef InSpec • InSpec is a command line tool Installs on your workstation as a ruby gem or as part of the ChefWorkstation • Can be run locally, to test the machine it is executing on • Or remotely InSpec will log into the target and run the tests for you
- 19. Lifecycle – How Often Do You Check Security? • Single big scan, report mailed out with a “due date”? Considered done, not checked again • Yearly or twice-yearly massive scans with remediation firedrills? Common audit cycles, large projects around fixing found issues • Part of the software development lifecycle? “To the left” Regularly part of what is included in builds
- 20. Add InSpec to Build and Production Workflows • Run InSpec on build nodes Ensure they meet your requirements before builds are executed Run smaller targeted profiles on code check-in • Run InSpec in your integration environments Ensure no new settings, configurations, app features violate your security before they get to prod • Run InSpec in production Verify your entire fleet on a regular basis – don't wait for the audit! When a new vulnerability is announced, create a test and push to your hosts. Know in minutes how exposed you are Use an agent for regular reporting, or targeted scans for spot-checking
- 21. Execute InSpec $ inspec exec ./test.rb Profile: tests from ./test.rb Version: (not specified) Target: local:// File /tmp ✔ should exist ✔ should be directory ✔ should be owned by "root" ✔ mode should cmp == "01777" Test Summary: 4 successful, 0 failures, 0 skipped
- 22. Test Any Target Local: inspec exec test.rb SSH Remote: inspec exec test.rb -i ~/.aws/mandi_eu.pem -t ssh://ec2-user@54.152.7.203 WinRM: inspec exec test.rb -t winrm://Admin@192.168.1.2 -- password super Docker Container: inspec exec test.rb -t docker://3dda08e75838
- 23. Profiles • Collections of InSpec tests Group by team, by application, by platform • Each profile can have multiple test files included • Flexible! Create your own profiles for specific software you use Use included matcher libraries or write your own – they live in the profile • https://dev-sec.io/ for samples
- 24. Sample Profile: linux-baseline control 'os-02' do impact 1.0 title 'Check owner and permissions for /etc/shadow' desc 'Check periodically the owner and permissions for /etc/shadow' describe file('/etc/shadow') do it { should exist } it { should be_file } it { should be_owned_by 'root' } its('group') { should eq shadow_group } it { should_not be_executable } it { should be_writable.by('owner') } ...
- 25. Demo • Basic off-the-shelf CentOS system on AWS • Install ChefWorkstation and git • Download and run the linux-baseline profile • Remediate with the corresponding Chef cookbook from https://dev-sec.io
- 26. Resources • https://inspec.io • https://blog.chef.io/category/inspec • https://learn.chef.io/ • http://www.anniehedgie.com/inspec-basics-1 • Whitepaper featuring Danske Bank: https://www.chef.io/customers/danske-bank/ • Demo script: https://github.com/lnxchk/demos-inpec-2019H2
- 27. Seattle | September 16-17, 2019 Thanks! More info: https://chef.io/products/chef-inspec https://inspec.io
- 30. Select CentOS 7 from the Marketplace • Use a small instance - .micro should be fine for this • Tag X-Contact with your name and X-Customer with something like "InSpec Talk Delete after 7/15/19" or similar
- 31. Security Group • I use the default all-open security group, as there's nothing running but ssh on this machine. If you have another security group that is more locked down, that's fine, too.
- 32. Installs • Install ChefWorkstation from https://downloads.chef.io/chef-workstation/ curl –o cw.rpm <url> sudo rpm -ihv cw.rpm • Install git via yum sudo yum install -y git
- 33. Demo stage 1 – Detect with the linux-baseline profile git clone https://github.com/dev-sec/linux-baseline.git sudo inspec exec linux-baseline/ <<accept the product license here>> You'll have some number of errors; the default installs will always have too many things installed. This version: Profile Summary: 26 successful controls, 27 control failures, 1 control skipped Test Summary: 80 successful, 45 failures, 1 skipped
- 34. Demo Stage 2 – Correct with Chef Infrastructure Download the Chef cookbook that matches the linux-baseline profile via a policyfile workflow chef generate policyfile fix-security <<accept the license>> edit fix-security.rb edit-> run_list 'os-hardening::default' chef install fix-security.rb chef export fix-security.rb harden-linux cd harden-linux sudo chef-client -z
- 35. Correct with Chef con't ...things happening... Recipe: os-hardening::auditd * yum_package[audit] action install (up to date) Running handlers: Running handlers complete Chef Infra Client finished, 141/206 resources updated in 07 seconds
- 36. Demo Stage 3 – Re-check with InSpec cd .. sudo inspec exec linux-baseline ... Profile Summary: 52 successful controls, 1 control failure, 1 control skipped Test Summary: 124 successful, 1 failure, 1 skipped There's almost always at least one failure. Depending on the time you have left, you can work through the next part, creating a wrapper profile and skipping this step, or, conversely, if you audience is already chef-aware, adding an additional recipe to fix whatever it is.
- 37. The error in this example: × package-08: Install auditd (1 failed) ✔ System Package audit should be installed ✔ Audit Daemon Config log_file should cmp == "/var/log/audit/audit.log" ✔ Audit Daemon Config log_format should cmp == "raw" ✔ Audit Daemon Config flush should match /^incremental|INCREMENTAL|incremental_async|INCREMENTAL_ASYNC$/ × Audit Daemon Config max_log_file_action should cmp == "keep_logs" expected: "keep_logs" got: "ROTATE" (compared using `cmp` matcher)
- 38. Demo stage 4 – prepare for Automate with wrapper profile • Create a wrapper profile: inspec init profile my-hardening • Edit my-hardening/inspec.yml depends: - name: linux-baseline git: https://github.com/dev-sec/linux-baseline • Remove the example rm -f my-hardening/controls/example.rb
- 39. Stage 4 Create a new control file: $ vi my-hardening/controls/skip-auditd.rb include_controls 'linux-baseline' do skip_control 'package-08' end
- 40. Demo Stage 5 – run the wrapper profile sudo inspec exec my-hardening ... Profile Summary: 52 successful controls, 0 control failures, 1 control skipped Test Summary: 113 successful, 0 failures, 1 skipped
- 41. Wrapper Profiles
Notas del editor
- As more and more of the customer experience in many industries relies on how well they handle the human – technology relationship, more targets are created for bad things to happen. When we think about how many packages, services, files, libraries, bits and pieces are included in any running system, considering the potential for any one of those to be vulnerable can be overwhelming for even a well-staffed security team.
- Honda shut down an automobile production plant because of WannaCry. This story is particularly interesting in an InSpec context not just because of the presence of a virus that had remediation available from the upstream vendor, but further down in the story it talks about coordinating the needs of several teams – IT and plant automation, for example – who have different needs, risk profiles, and resources available to work on something like WannaCry. It still has to be dealt with; this is real money coming off the line that is being disrupted by security shortcomings. Text of article: In an example of just how persistent modern cyberthreats can be, automaker Honda Motors had to temporarily stop production at its Sayama plant in Japan this week after being hit by WannaCry, a malware threat the company thought it had mitigated just one month ago. The nearly 48-hour shutdown impacted production of about 1,000 vehicles at the facility, which does engine production and assembly for a line of vehicles including the Odyssey minivan and the Accord. A statement from Honda North America said the interruption at the Sayama Auto Plant was caused by the shutdown of several older production-line computers infected with the WannaCry virus. Systems at multiple Honda plants in Asia, North America, Europe, and China were found similarly infected with WannaCry, according to a different Honda statement quoted by Reuters and other outlets. WannaCry infected hundreds of thousands of computers worldwide last month using a Windows exploit dubbed EternalBlue that the US National Security Agency (NSA) originally developed for use against adversaries. Threat group Shadow Brokers publicly leaked the exploit earlier this year. Honda has not said if the infection only impacted its industrial control system (ICS) network or its IT network as well, or both. Neither has the automaker so far explained why it decided to shut down operations only in Sayama and not at any of the other locations where WannaCry was reportedly spotted. Honda first discovered the outbreak Sunday and began recovery work immediately. But it wasn't until Tuesday morning that the company resumed production at Sayama. The infection occured despite Honda's implementation of new measures to mitigate WannaCry when news of the malware first broke. But Honda's efforts apparently were insufficient for several older computers installed at the Sayama Honda plant, some media outlets have quoted the company as saying. The incident highlights how difficult it is for large organizations to secure every system on their network, especially against self-propagating malware such as WannaCry, says Paul Norris, senior systems engineer at Tripwire. "Organizations will generally secure the systems they know about," he says. "But most will have assets that are not managed or secured and are old legacy systems that haven’t been decommissioned," and remain vulnerable, Norris says. "It's harder for larger organizations to secure every asset within their environment, due to the size and complexity of corporate networks," he says. The challenges are exacerbated in an industrial control system environment where IT and cybersecurity organizations often have little visibility into all the assets that might be in place. In fact, up to 80% of all cyber assets in a plant can sometimes be invisible to cybersecurity personnel and often there is an incomplete inventory of IT-based assets as well, making them hard to protect, says David Zahn, general manager at ICS security vendor PAS. "If you can't see it, you can't protect it," he says. It is possible also that Honda may have known about the underlying vulnerabilities to WannaCry in its plant floor environment but decided not to patch right away because it did not want to disrupt operations. "Risk mitigation within an industrial process facility moves at industry pace – not hacker speed," Zahn says. Hopefully, incidents such as this will prompt organizations into answering basic cybersecurity questions for plant environments, he notes. "What are my cyber assets, where are my vulnerabilities, did an unauthorized change occur, and can I recover quickly if the worst case scenario happens." More details are needed to know how Honda got breached. But the incident shows the need for organizations to pay more attention to securing plant floors against cybersecurity threats, adds John Bambenek, threat intelligence manager at Fidelis Cybersecurity. "Large organizations have devices in low security environments that are necessary for their operations and in many cases, rely on factory employees not take actions that undermine the security of those environments," Bambanek says. That is a mistake, he adds. "These attacks can cause real impact and a factory not producing parts for a day has a large monetary impact to the organization."
- A second example of lax security resulting in real dollars being lost because of a common oversight. It's not unusual for the default configurations in any system to be insecure; ease-of-use often takes precedence over tight security when there are end users involved who aren't necessarily technical experts. This problem plagues not just corporate IT, but also technical consumer goods and IoT. Text of article: A Catholic health care system has agreed to pay $2.14 million to settle claims it failed to change the default settings after installing new server, allowing public access to the private health records of 31,800 patients. St. Joseph Health – which operates hospitals, community clinics, nursing facilities and provides a range of other health care services – agreed it was in potential violation of security rules of the Health Insurance Portability and Accountability Act (HIPAA). The U.S. Department of Health and Human Services’ Office of Civil Rights (OCR) opened an investigation on Feb. 14, 2012, after St. Joseph Health reported that files containing electronic protected health information had been publicly accessible via Google and other browsers during the entire preceding year. “The server SJH purchased to store the files included a file sharing application whose default settings allowed anyone with an Internet connection to access them,” OCR said in an Oct. 17 statement announcing the settlement. “Upon implementation of this server and the file sharing application, SJH did not examine or modify it,” the statement continued. “As a result, the public had unrestricted access to PDF files containing the ePHI of 31,800 individuals, including patient names, health statuses, diagnoses, and demographic information.” See also: Merger of Two Healthcare Giants Makes IT Transformation Inevitable Federal investigators determined the health care nonprofit failed to coduct a thorough evaluation of the environmental and operational implications of installing the new server. Also, multiple contractors hired by St. Joseph to assess risks and vulnerabilities of ePHI were brought on in a patchwork fashion that did not result in the enterprise-wide risk analysis required by HIPAA. “Entities must not only conduct a comprehensive risk analysis, but must also evaluate and address potential security risks when implementing enterprise changes impacting ePHI,” OCR Director Jocelyn Samuels said in a statement. “The HIPAA Security Rule’s specific requirements to address environmental and operational changes are critical for the protection of patient information.” See also: HIPAA Breach Case Results in Record $5.5M Penalty In addition to the financial payment, St. Joseph Health agreed to a corrective action plan that includes a thorough risk analysis, implementation of a risk management plan and staff training. The $2.14 million penalty brings the total amount of settlements for HIPAA security violations to $22.84 million this year, up sharply from $6.2 million in all of 2015.
- Additionally, it's not uncommon for each of our stakeholders to have different knowledge, resources, and guidelines to adhere to. Compliance requirements are often set out in flat documents. Sometimes PDFs, sometimes other formats, but they have a tendency to be a huge list of characteristics and checkboxes to be investigated and potentially remediated. They often come from industry standards bodies or governments. Security tools may be somewhat more flexible, encoded into a set of shell scripts that check and verify the systems after they are built. These are often shipped by upstream software providers when a breach or bug is found. Operational tools deal with the day-to-day building and management of systems, and might include components that are homegrown and some that come from vendors. These various sources and requirements play into the overall security picture of technical infrastructure.
- For the purposes of compliance, we actually wanted a common language, in code, that would allow all audiences – compliance, security, and devops – to collaborate on. And this code will then act on systems. This is why Chef InSpec was developed.
- InSpec's early use was directed at testing the code used to automate infrastructure configuration – chef recipes, puppet modules, ansible playbooks. But its large solution set and capabilities also give it power beyond those environments, and it can be run standalone with whatever remediation your team prefers to use.
- Removing legacy network services helps prevent unwanted access to systems. Some of these services have their uses, but many have modern replacements that were built with more security in mind. You may still find these services included in full-distribution installs from various vendors. I've replaced the original SSH example; it no longer works on/applies to current releases of Linux; openssh no longer supports protocol 1, and the check for versions is not universal. http://undeadly.org/cgi?action=article&sid=20170501005206 The old version is here: SSH supports two different protocol versions. The original version, SSHv1, was subject to a number of security issues. All systems must use SSHv2 instead to avoid these issues. This directive is fairly common; it’s included in the security benchmarks published by CIS for a number of Linux and Unix systems that include SSH as a connection protocol. Many modern versions of these operating systems have version 2 as the default but include legacy support for version 1. It’s still a good idea to ensure that your systems are set to only use version 2.
- This test will tell you on red hat-related Linux hosts that the two packages xinetd and inetd are not installed on the system. This full control for InSpec has detailed information about what the requirement is – do not run these deprecated services – as well as a location of the documentation (here truncated to fit on the slide). This example uses the nsa guidelines, and the configuration follows the headers included in the documentation, so only xinetd and inetd are included in this control. The other services would also have similar controls that can be traced back to guidelines, or could have CVE numbers, ticket numbers from a ticketing system, or other notations for where the requirements were adopted from. "Steve in security sent an email on June 20 2019 telling us to clean this up". The control gives you the ability to group security requirements together – I could also include the other services here if I wanted to, but can also make them their own controls. The impact tells me this is a requirement – impacts range from 0.01 to 1.0. The InSpec resources, the two "describe package" directives, tell InSpec to go looking on the target systems for those packages. InSpec figures out the correct tools to do this with.
- InSpec's resources have powerful libraries for matching and checking the characteristics of individual atomic resources – like files or services. They also have support for more sophisticated verifications on the system. Individual configuration files can be interrogated for settings, like the example here for auditd. Additionally, the ability to run arbitrary commands is powerful for situations where a fix for a vulnerability has been produced by an upstream vendor and includes some sort of shell script rather than a new package. These are fairly common for things like kernel-level issues that require multiple checks and changes in settings files and also verification in the running kernel filesystem
- For our previous example with network services, how do you make sure a new service hasn't been installed that violates these requirements? If something is installed, how long does it remain before your testing finds it? For bits like the ssh configurations, or network services, or other components that are considered more infrastructure than application, these practices are common, changes are periodically rolled into the source images for new hosts (or containers) and the old configurations are eventually purged from production. It’s a herd-immunity approach. But what happens if the thing to be tested is affected by a continuously developed application? Like run time configurations for java, or your databases. Can you count on every team to always know all of the requirements? When the requirements change – we're moving all of our databases to a new port – how does that information get out to all teams, how is it rolled out across systems, and who ensures that nothing gets reverted in the future, even inadvertently?
- The point here is that running a twice-yearly audit and then spending six months remediating issues is a deadend task. With InSpec, applications can be shipped and deployed on hosts that you know meet your standards, and InSpec can then be used to make sure nothing drifts over time. Keep an eye on your systems regularly rather than just at audit.
- A simple example that checks for settings on the /tmp directory.
- If you have time, walk through the layout of a profile on github. The dev-sec.io ones are pretty complex, but have a lot of important stuff in them.
- Large platform-focused profiles like linux-baseline include tests collected into subtopics for easier management and understanding. The os-* tests are in a separate file from tests that are looking at specific packages. This also shows again the amount of user-friendly information that can be included in the title and description of a control. This particular test I chose because it has a lot of tests for a single resource, giving a comprehensive set of checks for an important file.
- Add upcoming events, webinars, etc to this slide
- Using AWS. If you prefer some other cloud that provides CentOS 7, this example should still work fine!
- Nothing special. This is the default ami available.
- I'm going to do the next part with a wrapper profile example. Depending on current versions of linux, the default install, and the state of the linux-baseline, this error changes, but this setting for auditd turns up pretty often when using CentOS 7 on AWS. Other stuff includes settings for the random number generator, prng.
- 0 failures! Yay! A few minutes from a baseline off-the-shelf random image in the cloud to a system that meets our security needs!
- You can use this diagram to show the relationship between the baseline profile and the wrapper profile