Security expert Bruce Schneier dragged an uncomfortable but very real possibility into public view during RSA Conference 2017, and it should have developers of all types pondering a very grim future full of software regulations.
Schneier discussed his case for internet of things (IoT) regulation in not one but two sessions at RSA Conference 2017 last week. The growing potential for IoT regulations are hardly a surprise given the run of recent high-profile DDoS attacks using insecure IoT devices. And while Schneier’s support for IoT regulations may have surprised some, he made a well-reasoned case that government action is coming whether the technology industry approves or not and IT professionals would be well-served by taking an active role in the process to ensure the government enacts the least-bad option.
Within one of those RSA Conference sessions, Schneier urged the audience to think more broadly about the responsibilities of developers in a “connect it all” world.
“We need to start talking about our future. We rarely if ever have conversations about our technological future and what we’d like to have. Instead of designing our future, we let come as it comes without forethought or architecting or planning. When we try to design, we get surprised by emergent properties,” Schneier told the audience. “I think this also has to change. I think we should start making moral and ethical and political decisions about how technology should work.”
Schneier then made another point that went far beyond simple IoT regulations and had chilling implications for the technology industry.
“Until now, we have largely given programmers a special right to design [and] to code the world as they saw fit. And giving them that right was fine, as long as it didn’t matter. Fundamentally, it doesn’t matter what Facebook’s design is,” he said. “But when it comes to “things,” it does matter, so that special right probably has to end.”
First, Schneier is obviously right. Facebook’s software design affects a very large but finite number of people, and they can choose to stay on or leave the platform; whatever programming sins it may commit won’t extend to users at Microsoft or Google or other companies. A connected physical device, however, can extend outside of Facebook’s user base and affect others. To this point, we’ve gotten off easy by only having to contend with potent DDoS attacks and data breaches. But the possibility of physical harm from hacked IoT devices is certainly in play.
That doesn’t make the possibility of general software regulations any easier to swallow, however. The idea that programmers could lose the right to code what they want and how they want seems as incomprehensible as the government suddenly regulating what I write as a journalist. While the latter scenario is clear violation of the Constitution, the former probably isn’t (more on that in moment).
I don’t know if Schneier truly believes that software developers should have their rights curbed by the government, or if his aim was to spark concern – and potential action – from the audience. Maybe it was both.
But is Schneier’s idea – that unfettered freedom for programming should be replaced with software regulations – really that far-fetched? Consider the aggressive measures proposed in Congress regarding the “going dark” issue and encryption technology. And keep in mind it was the judiciary and not lawmakers that ordered Apple to design a tool to hack its own security protections for iOS. (At one point before achieving a legal victory in this case, Apple was reportedly preparing an argument that its code was protected as speech under the First Amendment, which would have be fascinating to see.)
I mostly agree with Schneier’s argument that government regulation is coming whether we like it or not. There seems to be little incentive — and even less desire — for the industry to solve these IoT security problems. Perhaps that will change as IoT-related attacks become more common and more powerful this year. But perhaps not; the fact that manufacturers have allowed outdated connected medical devices to linger with known vulnerabilities gives me little confidence.
What would these regulations look like? During the question-and-answer session, Schneier was asked about whether certifications, either for individuals or for technologies, could address some of the concerns about connected devices leading to physical harm. Schneier said government-regulated certifications or licenses for software developers were a possibility.
“You had to be a licensed architect to design this building,” Schneier said, referring to the hotel at which the session was hosted. “You couldn’t be just anybody. So we could have that sort of certification – a licensed software engineer.”
I’m neither a structural engineer nor a programmer, but this seems like a bad idea. There aren’t that many ways to design a structurally sound building relative to the vast number of ways a programmer could design a perfectly sound application. The complexity of software doesn’t lend itself to the kind of regulation we see with building codes, for example. Even if the codes for coding, so to speak, were straightforward and tackled only the no-brainers – Thou shalt not use SHA-1 ever again! – there is a haystack’s worth of questions (backward compatibility, support, enforcement, etc.) that need to be answered, with no guarantee of actually getting to the desired needle.
If we accept a world in which a hypothetical government agency dictates what devices can and cannot be connected to the internet and how they are connected, it’s worth asking now what it will mean in the coming years for potentially broader, sweeping software regulations. It’s possible the Trump Administration’s stated commitment to roll back federal regulations will buy the IT industry some time before such a future is realized.
On the other hand, we’re one bad headline away from Congress enacting knee-jerk legislation to police not just how IoT devices are built and connected but how developers write and deploy code across the entire digital realm. And unlike journalists, programmers may have nothing in the Constitution to prevent it.
SAN FRANCISCO — While much of the talk at this year’s RSA Conference has been about future IoT threats and new attacks, Intel Security’s Christopher Young urged attendees not forget the past — specifically, the Mirai botnet.
“We can’t think of the Mirai botnet in the past tense,” Young, senior vice president and general manager at Intel Security, said during his keynote Tuesday at RSA Conference 2017. “It’s alive and well today and recruiting new players.”
To illustrate his point, Young described how Intel Security CTO Steve Grobman and his team decided to test the theory that Mirai was still highly active and looking for more vulnerable IoT devices to infect.
“Our hypothesis was simple,” Young said. “Given the amount of connected or infected devices that are out there today, what’s the risk that a new, unprotected device can be coopted into the Mirai botnet? We wanted to know, how pervasive was this threat?”
To that end, Grobman’s team set up a honeypot, disguised as a DVR, on an open network. And in just over a minute, Young said, they found the DVR had been compromised by the Mirai botnet.
“It just puts a fine point on the problem,” Young said. “The Mirai botnet is alive and well, recruiting drones…that can be used for the next attack.”
As a result, Young said the industry needs to address the insecurities of connected devices within the home, which have become lucrative targets for Mirai and other types of IoT malware. He stressed that a combination of approaches are required to address these IoT threats, including consumer education, changes in security policies for device manufacturers and better protection measures from the infosec industry.
“The question I’d ask all of us in cybersecurity here at RSA is: ‘How many of us take the home into account when designing our cybersecurity architectures and when we provision our cybersecurity tools?’” Young asked the audience.
Young said the threat landscape has changed, and as a result so too must the mentality of security professionals. “Today, the target has now become the weapon,” he said, referring to connected devices. “The game has changed on us yet again.”
RSA Conference 2017 officially kicks off Monday, and once again it will bring several topics, trends and potential controversies to the center of attention of the information security industry. Unlike previous RSA conferences, this year it’s been harder to identify one or two major themes heading into the show. But there are several storylines I’ll be following closely at RSA Conference 2017, starting with these five:
1. Rise of the machine learning model
Machine learning has been a persistent buzzword in the infosec industry recently, and that should continue at this year’s RSA Conference. Vendors big and small have moved away from signature-based antivirus and antimalware products to embrace machine learning models that no longer rely on existing malware definitions to detect threats. The antivirus software market has come under heavy scrutiny lately, thanks to head-scratching security flaws and persistent questions about the software’s effectiveness. But it remains to be seen if advanced threat detection products leveraging machine learning will be the true heir apparent. There’s also considerable confusion around the differences between machine learning and artificial intelligence, thanks to vendors using the terms interchangeably. Hopefully this year’s show will provide some clarity.
2. DDoS denial
Distributed denial of services (DDoS) attacks have long been a thorn in the sides of many enterprises, but until recently DDoS attacks have typically been viewed as minor nuisances rather as than major threats. That may be changing in the wake of the powerful Mirai botnet attacks last year. Several vendors and service providers are poised to deliver new mitigation products to combat these potent DDoS attacks. But the attacks have also led to growing concerns about the insecurity of internet of things (IoT) devices as well as potential legal or regulatory actions that may follow those concerns; both subjects will be addressed at the conference. And it’s unclear whether the infosec industry as a whole will be ready when the next wave of record-setting DDoS attacks takes aim at critical internet infrastructure.
3. The Trump effect
RSA Conference has been home to controversies in the past, and this year’s show is likely to host yet another one. A number of technology companies, organizations and conferences have spoken out in recent days against President Trump’s controversial executive order barring entry into the U.S. for people from seven Muslim-majority Middle Eastern countries. In the week before RSAC 2017 several technology companies, including Microsoft, Google and Intel, signed an amicus brief opposing Trump’s executive order; RSA, however, was not on the list. RSA Conference said last week it has not been impacted by the executive order. But the conference will feature Rep. Michael McCaul (R-Tex.) as a keynote speaker Tuesday; McCaul, chairman of the Homeland Security Committee, was initially a strong supporter of Trump’s action, though he later qualified that support, and reportedly contributed to the executive order. McCaul has appeared at previous RSA Conferences and has spoken out against encryption backdoors, but his support of the controversial executive order could earn him criticism from some attendees.
4. RSA’s direction
RSA itself has undergone major changes recently. Not only has the security vendor done an about face with its product portfolio, leaving behind its legacy encryption business in favor of identity and access management, but it experienced another executive leadership change recently. Former RSA President Amit Yoran departed the company in December, just weeks before this year’s show, to take the CEO position at Tenable Network Security. Yoran was named RSA president in 2014 and took over from former RSA head Art Coviello during a turbulent period for the vendor (RSA was criticized over reported ties to the U.S. National Security Agency). While RSA quickly tapped Rohit Ghai, formerly president of Dell EMC’s Enterprise Content Division, to fill the void, Yoran’s departure comes at a time when RSA is still trying to establish its new identity and questions about the company’s future with Dell EMC (or as an independent entity or acquisition target) persist.
5. Cloud security shakeup
Setting aside recent activity from cloud giants like Amazon Web Services and Microsoft Azure, the cloud security market has been in rut in terms of innovation and excitement. Cloud access security brokers have dominated much of the attention in the market, but after a flurry of investments and acquisitions in 2015 and early 2016, even the CASB market has been quiet lately. But that may be changing as several CASBs have broadened their scope beyond protecting major SaaS applications and are now moving to address IaaS security. And that’s good news, considering the growing number of attacks either targeting cloud services or using them as command & control infrastructure for other targets. With the rush of cloud-focused products from traditional security vendors waning over the last year, a shot in the arm from CASBs could be just what the cloud security market needs.
In the past, the simple sharing of a Microsoft Word document with a colleague over email wasn’t cause for alarm. It wasn’t the kind of event that was regularly reviewed or even recorded by a security operations center.
Maybe it should’ve been. Regardless, in the age of rapid cloud adoption, such document sharing – even over email – is exactly the kind of event that, at least in theory, is monitored by today’s security operations centers (SOCs). And that’s become yet another problem on the growing list of security concerns for enterprises in the age of decentralized and mobilized IT environments.
Skyhigh Networks, a cloud access security broker, released its Q4 2016 Cloud Adoption and Risk Report earlier this month, and it included many data points one might expect: the number of cloud services used by the average enterprise, according to Skyhigh’s customer survey, continues to climb (1,427 services, currently); many of these cloud services still lack proper security controls (just 8.1% of those services meet Skyhigh’s Enterprise-Ready rating); and a growing percentage of files uploaded to cloud file sharing or collaboration services contain sensitive information (18.1%).
But the report also included surprising data on just how much cloud sharing and collaboration services are taxing security teams – even when there are no actual security incidents occurring. For example, according to Skyhigh’s survey, the average enterprise generates 2.7 billion cloud events per month (which includes everything from a file upload/download, document share and user logins).
But just 2,542 of those events on average are anomalous events, and an even smaller number – 23.2 – end up being actual security incidents. The Skyhigh report also states “Security teams widely report inaccurate breach notifications, resulting in alert fatigue and missed incidents.” In other words, the rapid growth of cloud file sharing and collaboration has sent the number of cloud events snowballing down a hill, and security teams are getting buried at the bottom.
“We hear a lot about alert fatigue. There are just so many cloud events and activities per month to monitor,” said Kamal Shah, senior vice president of products and marketing at Skyhigh. “All of those events go to the SOC, which just gets bombarded. They can’t keep up.”
The good news, of course, is just 23.2 of these monthly events constitute actual risks or threats to an enterprise (and even then, the incidents in question may be something as relatively simple as an accidental file exposure). The bad news is that even when things are working smoothly, security teams still struggle to stay above the water line because of the sheer volume of data they must monitor.
There are ways to address the problem, Shah said. User behavior analytics, for example, can help security teams better identify a potential threat and separate pertinent data from the rest of the noise. But, Shad said, companies need to start addressing the problem before they become paralyzed by the mountain of cloud events piling up on them.
“The number of cloud events is growing every quarter, and that makes it harder on enterprises because it’s just too much data,” he said. “And the number is only going to go up.”
There is certainly no shortage of infosec headlines mentioning some new Android malware threat. There are banking Trojans, malware that can root your phone, monitor your communication or steal your data. Given the frequency and bombast of the headlines, you might even think that Android is completely insecure and overrun by malicious apps. But this isn’t true for most in the Google world.
If you live in North America, Europe, Japan or Australia, your Android device almost certainly uses the Google Play Store for app discovery and installation. Malicious apps are sometimes found in the Play Store, but those are usually apps with little usage. Plus, Google often will have removed a malicious app from the Play Store by the time you see the news story about the risk.
Google’s statistics claim that 0.16% of the apps that users attempted to install from the Play Store in 2015 were found to be malicious. And various studies show that the average Android user only installs about one app per month. Basically, you really need to be unlucky to install a malicious app out of the 2.4 million available in the Play Store.
Going outside of the Play Store does bump up your risk factor, but there is still a process to installing a malicious app that news about Android malware tends to gloss over. The vast majority of Android malware is delivered to devices via “side loading,” which is to say the app has to be actively installed by the user outside of the Google Play Store environment. This is not a simple process.
In order to be able to side load an app, a user must first go into the device settings and turn on the option to install apps from “Unknown Sources” and tap OK on the dialog that pops up warning the user that side loading apps makes “your phone and personal data more vulnerable to attack.”
Then it is a matter of getting the malicious app onto a user’s device. Often, malware is hidden inside hacked versions of popular apps that are hosted on pirate download sites. So if a user wants to get a paid app for free, they might accidentally get malware as well. However, when a user attempts to install a malicious app, Google’s Verify Apps feature kicks in. Verify Apps will present the user with a warning at the time of install (which requires two taps to bypass) and even if a user confirms the installation, Verify Apps can remove apps that register as device admins or disable apps that “compromise the device security model.”
Of course, all of this assumes the user has an Android device with Google apps and services on it. Many devices sold in Russia, China and India do not have Google apps and services, which is why Android malware is far more prevalent in those regions.
But imagine the process of delivering malware to an Android device when needing to trick the user into downloading it: First, the user is deceived into downloading the malicious app. Then the user would have to find the app on the device (which could even require a file explorer app that is not always present on the device by default), attempt to install it and be warned that the installation cannot happen without changing the “Unknown Sources” setting. The user would have to change the setting, bypass that warning, attempt to install the app again, likely be warned again, bypass that warning and complete the install. At this point, depending on what version of Android the user has, this might mean approving the app permissions at the time of install; or, it might mean opening the app and approving permissions for the app to access the device storage. Even after all of that, Google’s Verify Apps might still step in and kill the app for you or Google’s Safety Net might catch the app attempting to contact a command and control server to download malicious code and shut that down.
That’s a complicated process that often gets ignored in the rush to put up a headline about some “dangerous” new Android malware. Just remember: a malicious app can’t appear on your device by magic. So, if you stick with established apps in the Google Play Store and avoid side loading apps, your chances of being infected by a malicious app are close to zero.
The cloud access security broker market has been keeping the U.S. Patent and Trademark Office busy.
SkyHigh Networks recently announced it obtained another patent for its CASB platform, the third such patent the company has been awarded since it was founded in 2011. SkyHigh’s announcement came shortly after rival Netskope announced it had been awarded a second patent for its own CASB platform.
SkyHigh’s most recent patent covers an “encryption key management system and method” for “an enterprise using encryption for cloud-based services.” The company’s technology features a hosted encryption service or gateway that can handle clients’ encrypted data as it moves to and from cloud services. Rather than enterprises having to send user traffic to cloud applications through an on premise encryption gateway, SkyHigh’s platform handles the process in the cloud.
From the patent abstract: “The network intermediary receives the encryption key material from the enterprise and stores the encryption key material in temporary storage and uses the received encryption key material to derive a data encryption key to perform the encryption of the enterprise’s data. In this manner, the enterprise can be provided with the added security assurance of maintaining and managing its own encryption key while using cloud-based data storage services.”
SkyHigh’s approach for securely managing the encryption keys involves several steps, according to the patent, including the generation of original key material using a key agent deployed within the enterprise network; storing the original key material on the key agent in a temporary memory; using the key agent to request a hardware security module to encrypt the original key material, which the HSM does using the using an enterprise owned and managed encryption key that is available only within the enterprise data network, and so on (for the full process, read the patent description).
If that sounds like a complicated process, that’s because it is. So why is it beneficial to have the encryption gateway hosted in the cloud rather than on the enterprise’s own network? Kaushik Narayan, co-founder and CTO of Skyhigh Networks, said there are operational hurdles to that method. “Previously, enterprises would have to use on premise encryption and key management for data in the cloud,” he said. “But if you’re on the road or outside the corporate network, you would need a VPN to get access to that data. That can make using cloud services a lot more difficult.”
Narayan stressed that SkyHigh’s patented approach doesn’t involve taking ownership of encryption keys from enterprises. “The keys are still owned and kept by the customers,” he said. “The idea behind the patent is to cover the acquisition and distribution of those keys.”
Other CASBs such as CipherCloud use similar hosted encryption approaches, so it remains to be seen if there will be any overlap or potential friction with SkyHigh’s patent. But the flurry of patents awarded to competing startups in the CASB space show just how quickly the market is evolving, and how valuable intellectual property in the CASB market can be.
The patent also further demonstrates how crucial encryption is to the CASB model in particular and cloud security in general. Narayan said SkyHigh, which last month announced $40 million in series D financing, has put greater focus on encryption because of customer demand.
“Encryption is a core component of the CASB model. Fundamentally where this all started is with customers in certain verticals like financial services and healthcare, as well as businesses in certain regions with strict regulatory concerns,” Narayan said. “When these customers put third party customer or citizen data in the cloud, they have to — for a variety of compliance reasons — protect that data.”
The struggling antivirus software industry has been in the news lately for all the wrong reasons.
To recap, Google’s Project Zero has discovered and disclosed a flurry of head-scratching vulnerabilities in many leading antivirus products. The most serious of these included critical flaws in the core engine of Symantec’s flagship antivirus software. To add insult to injury, the discovery of these Symantec vulnerabilities revealed a shocking design flaw in its products: the antivirus engine was loading itself in the Windows kernel to scan malware.
Bringing potentially malicious code in the Windows kernel is like putting Ozzy Osborne in a roomful of doves and hoping he’ll be on best behavior. The Symantec episodes were a sad reminder of the woeful state of the antivirus industry.
And now the beleaguered antivirus industry is back in the spotlight once again. This time, however, it’s not the fault of the security vendors.
Many top antivirus programs have been rendered useless on Microsoft systems that installed the Windows 10 Anniversary update. Users have reported problems with Kaspersky Lab, Intel Security, Avast and others, ranging from features being disabled in the AV programs to systems crashes and blue screens of death. Microsoft confirmed that the problem is with the Windows 10 Anniversary update’s compatibility checks, and expects a patch to be issued in September (Kaspersky has released its own temporary fix for the problem).
While the antivirus industry has been on the decline lately, Microsoft depends heavily on these products to protect Windows systems from the waves of malware flooding cyberspace. No enterprise worth its salt would allow its employees to rely solely on Windows’ own embedded security features to protect their systems. So one would expect that Microsoft would take extra care in making sure its update would be compatible with programs and not leave systems without proper security protection.
But apparently that didn’t happen. And the reason, according to Intel Security’s advisory, is pretty upsetting:
“The intent was to have upgrade and installation checks implemented in the Windows 10 Anniversary Update to ensure that no incompatible McAfee product versions could be installed or present. Because of time constraints, these checks could not be implemented prior to the release of the Windows 10 Anniversary Update on August 2, 2016.”
Time constraints? I find it hard to believe that Microsoft didn’t have the resources available to implement these checks and avert this headache. Antivirus vendors have had a hard enough time fighting threat actors and their own lackluster product quality. They really don’t need a third adversary in the ring with Microsoft.
Netskope recently obtained a second cloud security patent for its CASB platform, one that could prove extremely beneficial in an increasingly competitive cloud security market that puts a premium on intellectual property.
The CASB startup was awarded another patent earlier this year for technology that “steers” enterprise traffic to cloud applications and provides real time visibility for those apps.
The new patent covers Netskope’s technology that provides granular data governance and security policy enforcement on cloud applications. Netskope CEO Sanjay Beri called it a “broad patent” that covers the ability to set policies for cloud app usage based on a number of variables, including device type, user profile, behavioral analytics and, perhaps most importantly, what data is being accessed in that cloud app and what is being done with it.
“This is the other side to the approach,” Beri said. “The first patent was about steering traffic to control points. That’s how you get the traffic to the cloud services. The second patent is about what you do with the traffic when it gets there.”
Netskope’s policies, which customers themselves set, are able to distinguish between downloading, modifying and viewing data within cloud apps. For example, Beri said a retail customer concerned about cloud data being accessed by unmanaged personal devices could create a policy for an app’s data that allows users to view the data but not download it.
Beri said the power of the new patent is the technology’s ability to give enterprises the proper context in how their cloud apps can and will be used. Most web application firewalls use basic “block or allow” policies, he said, but CASBs like Netskope can provide more insight and control around how a cloud app and the corporate data tied to it are being used.
Technology patents don’t usually make for exciting news, but in the case of the CASB market, they provide insight into how startups have evolved – and how they’re being valuated by investors and suitors. CASBs have evolved from offering basic visibility into shadow cloud usage to providing secure gateways to cloud apps as well as access control, data protection and threat monitoring. As these CASBs have evolved and matured, they’ve patented their unique approach and developed intellectual property (IP) for those sets of services.
And those patents have proven to be valuable – perhaps more so than customer base or revenue – to potential suitors. Blue Coat Systems’ recent S1 filing for a potential IPO revealed that Perspecsys, a CASB startup acquired by Blue Coat last summer for $45.5 million, had posted revenue of just $2 million for the first half of 2015. But Michael Fey, then Blue Coat’s president and COO, said the Perspecsys deal was about obtaining the startup’s patent for tokenization technology in the cloud.
Similarly, Blue Coat acquired another CASB last November in Elastica, which, according the Blue Coat’s S1, generated just $395,000 in revenue between January and November of 2015. Yet Elastica was able to command a purchase price of $280 million, thanks in large part to its IP and patent-pending tech.
Beri said Netskope recognizes how valuable IP and patents are in the security industry, which is why they’re doubling down on research and development. “We have the largest R&D team in the CASB market,” he said. “So you’ll see more patents for us in the future.”
Outside of command line tutorials for Linux, the term “environment variable” increasingly appears right next to “security vulnerability.” Consider Shellshock — one of the worst exploitable flaws ever — which requires little more work than attaching malicious code onto an environment variable. More recently, the httpoxy vulnerability also leverages access through the HTTP_PROXY environment variable.
Are environment variables for suckers? Do we even need them anymore? Can we afford them?
SearchSecurity asked several experts whether it might be time to ditch environment variables, given that they enable vulnerabilities like Shellshock and httpoxy, or whether there are benefits to keeping them on hand.
“Environment variables are an essential part of how things run under unix/linux systems,” explained John Bambenek, manager of threat systems at Fidelis Cybersecurity in Waltham, Mass. Many environment variables are innocuous — for example, the PATH environment variable lists the directories in which the shell looks for binaries when a command is entered at the command line.
However, Bambenek said, “The problem is allowing the open internet to modify environment variables of significance — like HTTP_PROXY — that have real impact on those running applications. Accepting unauthenticated input from the world is always a very dangerous thing, reading that data into an environment variable that has real impact on the system is extremely dangerous,” and that’s what happened with the httpoxy vulnerability.
“I’m not sure how we do things without environment variables,” said Jacob Williams, founder of consulting firm Rendition InfoSec LLC, in Augusta, Ga. “They are a source of vulnerabilities, but not having them creates a whole new class of problems we’ll have to account for in the long run. I don’t know what the solution will be, but it will also create new vulnerabilities. It’s not the variables themselves, it’s the insecure use of the variables that creates problems.”
Deciding on whether it’s time to stop using environment variables depends on where they are used, according to Bill Berutti, president, performance & analytics and cloud management/data center automation, at business service management software firm BMC, based in Houston.
“For an enterprise application, it is always a good practice to pass on variables for the session of the process and not set in the environmental variables. This is a much better approach,” Berutti explained. “Nevertheless, environmental variables are useful in case of test/stage applications where there are a lot of clone applications being run on the same box to test out applications in parallel and/or it’s something standardized for all the applications running on that node.”
“There is nothing inherently wrong with environmental variables,” said Christopher Robinson, manager at Red Hat’s product security program management. Cloud services, for example, often use environment variables to distribute configuration data, though Robinson warned “programmers should always be cautious as to what data their programs accept and use for subsequent processing/directives.”
There’s no real security benefit to using environment variables, according to Lane Thames, security researcher at Tripwire Vulnerability and Exposures Research Team (VERT). “Regardless of where the data comes from (environment variable, database query, et cetera), it is up to the application that uses the data in the variables to ensure correctness and compliance.”
“I don’t know that we can without boiling the ocean,” said Dominic Scheirlinck, principal engineer at Auckland, New Zealand e-commerce firm Vend. “They’re in every new [platform as a service] and [continuous integration] system because they work well for simple, easy-to-use configuration.”
Scheirlinck, who is also the lead for the httpoxy disclosure team, added “I think it’s more likely that we should be much more careful, in the future, about accepting specs,” like the common gateway interface (CGI) specification, “that allow environment variables to be controlled by remote users.”
It’s becoming harder and harder for me to read about the glaring security holes, the bafflingly risky behaviors and the all-around worst practices of the healthcare industry and still maintain some semblance of composure and mental health. It feels as if each new study or research paper on healthcare security is pushing me closer to the point where I’ll be more terrified of seeing doctors using an outdated Windows XP client than watching them approach me with a scalpel or six-inch hypodermic needle. Or both.
Case in point: a study from researchers at Dartmouth College, the University of Pennsylvania and the University of Southern California has garnered media attention recently, as it shows the lengths doctors, nurses and clinicians will go to bypass security controls and authentication measures, which many view as impediments to their jobs. “Workarounds to computer access in healthcare are sufficiently common that they often go unnoticed,” the study reads. “Clinicians focus on patient care, not cybersecurity.”
The title of the paper – “Workarounds to Computer Access in Healthcare Organizations: You Want My Password or a Dead Patient?” – offers a big hint about the mentality of medical professionals when it comes to the topic of information security. The study, in which researchers interviewed and observed hundreds of medical workers, at different hospitals and medical centers, showed how doctors, nurses and other medical professionals are so desperate to avoid cumbersome login and authentication processes that they will resort to almost absurd practices to get around them.
But in case the title and summary aren’t enough, here are some points from the study:
- “Clinicians share passwords with others so that they can read the same patients’ charts even though they might have access in common. A misbehaving hospital technician used a physician’s PIN code to create fake reports for patients.”
- The study documented “physicians ordering medications for the wrong patient because a computer was left on and the doctors didn’t realize it was open for a different patient.”
- “Nurses would circumvent the need to log out of COWs [computers on wheels] by placing “sweaters or large signs with their names on them” or hiding them or simply lowering laptop screens.”
- The study cited a previous report about how “clever clinicians at one hospital defeated proximity sensor-based timeouts by putting Styrofoam cups over the detectors, and how (at another hospital) the most junior person on a medical team is expected to keep pressing the space bar on everyone’s keyboard to prevent timeouts.”
- “One vendor even distributed stickers touting ‘to write your username and password and post on your computer monitor.’ A newspaper found a discarded computer from a practice contained a Word document of the employees’ passwords — conveniently linked from a desktop icon.”
Medical professionals, however, don’t bear the full blame for these terrible healthcare security practices. The study points out how some of the inadequate IT systems used in hospitals can promote this kind of delinquency. For example, the paper cites an example of a physician who uses the clinic’s dictation system – which has a five-minute session timeout and requires users to re-authenticate (which takes approximately one minute) to log back in; the physician told the researchers he spent nearly an hour-and-a-half logging in one day.
Another example involved a large city hospital, which required a digital thumbprint to authenticate each death certificate. But only one of the doctors on staff had thumbs that could be read by the digital reader. “Consequently, only that one doctor signs all of the death certificates, no matter whose patient the deceased was,” the report stated.
Still, however dysfunctional the technology and legacy systems at hospitals are, these access and authentication workarounds are just more examples of how easy the healthcare industry makes it for attackers to breach their networks. Attacks on hospitals and healthcare organizations are on the rise, and we’ve seen repeated examples of how vulnerable hospitals are to such attacks. It’s time the healthcare industry to address these counterproductive behaviors and woeful technology before the medical records and personally identifiable information of every U.S. citizen becomes public domain — if they aren’t already.