Prescriptive Security with InSpec - All Things Open 2019

Editor's Notes

• #5: 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."
• #6: A second example of lax security resulting in real dollars being lost 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.
• #7: 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.
• #8: 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 whyInSpec was developed.
• #12: 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.
• #14: 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.
• #15: Deprecated SSHv1 example
• #16: 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?
• #17: 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.
• #22: 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
• #24: A simple example that checks for settings on the /tmp directory.
• #26: 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.
• #27: 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.
• #29: Add upcoming events, webinars, etc to this slide
• #31: Using AWS. If you prefer some other cloud that provides CentOS 7, this example should still work fine!
• #32: Nothing special. This is the default ami available.
• #39: 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.
• #42: 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!
• #45: You can use this diagram to show the relationship between the baseline profile and the wrapper profile