In this episode of the podcast (#216), sponsored by Digicert, we talk with Brian Trzupek, Digicert’s Vice President of Product, about the growing urgency of securing software supply chains, and how digital code signing can help prevent compromises like the recent hack of the firm SolarWinds.
We spend a lot of time talking about software supply chain security these days? But what does that mean. At the 10,000 foot level it means “don’t be the next Solar Winds” – don’t let a nation state actor infiltrate your build process and insert a backdoor that gets distributed to thousands of customers – including technology firms three letter government agencies.
OK. Sure. But speaking practically, what are we talking about when we talk about securing the software supply chain? Well, for one thing: we’re talking about securing the software code itself. We’re talking about taking steps to insure that what is written by our developers is actually what goes into a build and then gets distributed to users.
Digital code signing – using digital certificates to sign submitted code – is one way to do that. And use of code signing is on the rise. But is that alone enough? In this episode of the podcast, we’re joined by Brian Trzupek the SVP of Product at Digicert to talk about the growing role of digital code signing in preventing supply chain compromises and providing an audit trail for developed code.
Brian is the author of this recent Executive Insight on Security Ledger where he notes that code signing certificates are a highly effective way to ensure that software is not compromised -but only as effective as the strategy and best practices that support it. When poorly implemented, Brian notes, code signing loses its effectiveness in mitigating risk for software publishers and users.
In this conversation we talk about the changes to tooling, process and staff that DEVOPS organizations need to embrace to shore up the security of their software supply chain.
“It boils down to do you have something in place to ensure code quality, fix vulnerabilities and make sure that code isn’t incurring tech debt,” Brian says. Ensuring those things involves both process, new products and tools as well as the right mix of staff and talent to assess new code for security issues.
One idea that is gaining currency within DEVOPS organizations is “quorum based deployment” in which multiple staff members review and sign off on important code changes before they are deployed. Check out our full conversation using the player (above) or download the MP3 using the button below.
The recent SolarWinds attack highlights an Achilles heel for enterprises: software updates for critical enterprise applications. Digital signing of code is one solution, but organizations need to modernize their code signing processes to prioritize security and integrity and align with DevOps best practices, writes Brian Trzupek the Senior Vice President of Products at DigiCert in this thought leadership article.
Even in today’s security-charged world, the SolarWinds breach was a wakeup call for cybersecurity professionals. It was distinguished by its sophistication and the fact that it was carried out as part of legitimate software updates. The incident was quickly all over the news and has brought renewed focus on need for secure DevOps.
In this episode of the podcast, we bring you the second installment of our interview with Jeremy O’Sullivan of the Internet of Things analytics firm Kytch. (The first part is here.) In this episode Jeremy talks about the launch of Kytch, his second start-up, which helped owners of soft ice cream machines by the manufacturer Taylor to monitor and better manage their equipment. We hear about how what Kytch revealed about Taylor’s hardware put him at odds with the company and its long-time partner: McDonald’s.
We generally view and talk about phenomena like “digital transformation” in a positive light. The world’s growing reliance on software, cloud computing, mobility and Internet connected “things” is remaking everything from how we catch a cab, to how we grow food or educate our children.
But what happens when that “digital transformation” is transformation to something worse than what came before, not the better? What happens when technology isn’t used to build a “better mousetrap” but to support a racket that enshrines expensive inefficiencies or a monopoly that stifles competition?
What the hell is going on?
In his week’s episode, we’re digging deep on that question with the second installment of our interview with Jeremy O’Sullivan, the co-founder of the Internet of Things intelligence start-up Kytch. As we discussed last week, O’Sullivan and his wife, Melissa Nelson, launched the company in an effort to use data analysis to revolutionize the industrial kitchen, starting with one common but troublesome piece of machinery: soft ice cream machines manufactured by the company Taylor and used by the likes of McDonald’s and Burger King.
“What the hell is going on with the software on this ice cream machine? Why as the versions increase…is the software getting worse?”
– Jeremy O’Sullivan of Kytch on the Taylor soft ice cream machines.
The Dark Possibilities of Digital Transformations
In this episode, O’Sullivan talks about how – as McDonald’s franchisees scooped up Kytch devices- his understanding of Taylor’s “business model” changed, even as the relationship with the company soured, culminating in what O’Sullivan alleges was the theft of a Kytch device and the reverse engineering of its proprietary technology.
Far more than a story about massive, wealthy incumbents crushing a smaller challenger, the Kytch story is one that hints at the dark possibilities of digital transformation, as equipment makers use software to lock out their customers and deliver on “planned obsolescence.”
We start with Jeremy’s account of how his relationship with Taylor, which had been amicable when he was trying to build Fro Bot, a platform for stand-alone yogurt and ice cream kiosks, suddenly soured when he introduced the Kytch product and began giving Taylor customers better control over their equipment. The relationship with Taylor and its partner, McDonald’s, went down hill fast from there, as Taylor’s previously friendly management cut off contact with O’Sullivan and Kytch.
Law Suit Filed
In recent weeks, O’Sullivan and Kytch filed suit against Taylor and one of its major distributors for breach of contract, misappropriation of trade secrets and “tortious interference.” (PDF) Kytch alleges, among other things, that the company – working with a customer who was a prominent McDonald’s franchisee and a Taylor distributor – illegally obtained a Kytch device and reverse engineered it. Soon after, the company announced that it would be launching its own Kytch like device in 2021. At around the same time, McDonald’s warned franchisees using the Kytch device that doing so could violate its warranty with Taylor and put its employees physical safety at risk – a message that many franchisees interpreted as a warning against using the device from McDonald’s corporate leadership.
For O’Sullivan, the behaviors reinforced concerns and misgivings he had about Taylor after analyzing data from the large number of Kytch devices deployed in McDonald’s in other restaurants. The company’s software, he said, seemed to get worse over time not better – with each software update introducing more instability – not less- more ways for the ice cream machines to break down, not fewer. Most suspicious of all: Taylor refused to talk about it.
“These people don’t want to have a forthright, open conversation about their software because they’re using for malicious means – to support their healthy service and repair business.”
A Fairytale of the Deflating Variety
In this podcast, we talk with Jeremy about his experience with Taylor and McDonald’s, the role that software can play in creating powerful constraints on customers and the marketplace. We also discuss the lawsuit Kytch filed and some of the other unseemly revelations contained in his suit.
For O’Sullivan, the lessons of his experience aren’t the uplifting kind. “This is a very sad story and a very un-American story,” O’Sullivan told me. If Kytch was a “vaccine” for the virus of software-driven inefficiency, the real story is about the virus and the “McDonald’s industrial complex” that gave rise to it, not his company’s cure for it.
“This is crazy because it’s a story about McDonald’s that is also about the demise of McDonald’s. McDonald’s is supposed to be a symbol for America and a forward thinking tech-oriented company and its really exposes how the company has devolved.”
Check out the podcast by clicking the button below!
Overworked, understaffed teams? Reactive processes? Noisy tools and a river of false positives? Welcome to the “SOC hop,” the dysfunctional “normal” of the typical corporate security operations center (SOC). But it is a normal that is not sustainable, writes Steve Garrison of Stellar Cyber in this Security Ledger expert insight.
There have always been two ways to view the Security Operations Center (SOC). Idealized, the SOC runs with precision and control. Operations are linear, it is well staffed, and the workload is reasonable. Surprises may occur, but they are readily handled in stride. There is no real sense of panic or fatigue, because everything works as planned. Then there is the other view of the typical SOC, the one experienced by most companies. This is the SOC hop.
Enter the SOC Hop
The hop is characterized by an overworked, understaffed team that is constantly jumping from one fire to the next. As much as the team is qualified and desirous of being proactive, all their time is consumed by reacting to events and alerts. Most of the professionals are exhausted and some even question the value of certain tools that have too many false positives and lack the ability to prioritize alerts in a meaningful, productive way. Ultimately, the SOC hop is not sustainable. Security success is getting worse, not better, and a data breach or something even worse seems a foregone conclusion.
Fortunately, organizations are rethinking the SOC and how it works in a classic “there must be a better way” reevaluation. The SOC is being reimaged or reimagined to better deal with the realities of today and the ability to scale to challenges still to come. The considerations may seem trite or tired—all too familiar—but they represent the fundamental changes needed to leave the SOC hop and move on to something better.
The SOC: re-imagined
First, there is visibility. Everyone knows this. An old security adage is “you can’t secure what you cannot see.” This is just as true today as when it first became a cliché. Visibility is a combination of depth and breadth. Attackers may target any portion of an attack surface and will traverse networks and infrastructure to gain access to valuable assets. This means that every part of the attack surface must be monitored and that organizations can see across their entire infrastructure to find the East-West activities intrinsic to the work of a skilled attacker. At the same time, data must also provide contextual references for an event to help boost accuracy and understanding of findings.
Second, the re-imaged SOC needs combined intelligence. The silos of separate tools with their individual alerts—and SIEMs that cannot gather a deep and broad enough amount of data to provide comprehensive understanding and relevant admonitions—need to be united. Not only do security tools and systems need to connect, they need to correlate their data to help paint a broader, clearer picture of potential in-progress attacks. This is more than API connectivity and rudimentary integrations. It also means real time or close to real time. Again, attacks are not static; they are dynamic and attackers move, conducting a campaign to maximize the return on their activity. One event may be inconsequential and below the radar, but connecting the dots may clearly reveal an attack in progress.
Mind the Gap
Third, gaps need to be covered. There are normally gaps between coverage areas and the realm that each security tool ingests. Logs will only reflect a portion of the evidence. There are typically some kind of boundaries between what is monitored as perimeter, endpoint, cloud, server, data center, etc. In addition, gaps may come into being through the natural, dynamic change of a company’s networks and infrastructure. Ideally, gaps can be met with sensors to ensure full visibility and assessment. Data from these sensors may be instrumental in finding attack activity or bolstering findings.
The combination of full visibility, covering gaps and combined intelligence can be a game-changer for the SOC. It can substantially change the way the team works. Rather than hopping from incident to incident or between every alert or event that pops up, the cacophony of disparate can be put to an end to produce alerts that are fewer in number, higher in accuracy and relevance and prioritized for action. Here, the tools support the SOC team rather than the other way around. The tiresome SOC hop can give way to a wholly new way of working and getting an upper hand on the many challenges of protecting data, infrastructure and valuable assets.
In this episode of the podcast (#214), Brandon Hoffman, the CISO of Intel 471 joins us to discuss the recent ransomware attack on the Georgia-based Colonial Pipeline, and the suspected group behind it: DarkSide a ransomware for hire cybercrime outfit.
It was just a week ago, May 7th, 2021, that a successful cyberattack against one of the largest U.S. oil and gas pipelines, operated by the Colonial Pipeline Company, forced it to shut down and plunged the U.S. government into an unanticipated crisis. Within days, there were reports of consumers panic-buying petrol leading to gas shortages in the southeastern United States.
Then, almost as suddenly as the crisis appeared it was over. Colonial, which was reported to have paid the Darkside group a $5 million ransom to regain access to their servers, announced that it would restore pipeline operations by the end of the week. And, in a message to a private forum on Thursday captured by the firm Intel 471, the ransomware group credited with the attack, known as “Darkside,” said that it was shutting down after its blog, payment server and Internet infrastructure were seized by law enforcement and cryptocurrency from a Darkside controlled payment server was diverted to what was described as an “unknown account.”
Other news reports suggests the cyber criminal underground was getting skittish about ransomware groups, now that the full force of the U.S. government appears to be focused on rooting them out. Reports out Friday claim that the Russian cyber hacking forum XSS has banned all topics related to ransomware.
What happened? And who – or what – is the Darkside group responsible for the Colonial pipeline attack? We invited Brandon Hoffman, CISO at the firm Intel 471 back into the studio to talk about Darkside, which Intel 471 has followed and profiled in depth since it emerged last summer.
“They (DarkSide) don’t necessarily want to have their affiliates attack Critical Infrastructure or the government.”
-Brandon Hoffman, CISO Intel 471
The quick collapse seen in recent days may be a case of Darkside biting off more than it can chew by attacking a target that managed to put it in the cross hairs of the U.S. government. But, as we discuss, the Colonial Pipeline hack also raises a number of questions regarding the state of America’s Critical Infrastructure, and whether it is secure enough to withstand both directed and opportunistic attacks. “Ransomware is no longer a cybercrime problem, it’s really a national security issue,” Brandon tells me.
In this conversation, Brandon briefs us on DarkSide and outlines the group’s motivations and processes when it works with affiliates and targets victims. The attack on Colonial will almost certainly prompt changes by attackers, which will be wary of inviting retaliation from nations like the U.S.
Carolynn van Arsdale (@Carolynn_VA) contributed to this story.
It already seems like a lifetime ago that the hack of the Orion network management software by SolarWinds consumed the attention of the media, lawmakers and the for-profit information security industry. In reality, it was barely six months ago that the intrusion first came to light.
In the space of a few months, however, there have already been successive, disruptive events of at least the same seriousness. Among them: the attacks on vulnerabilities in Microsoft’s Exchange Server and – in the last week – the ransomware attack that brought down the Colonial Pipeline in the Eastern United States.
Lessons Still Being Learned
The “party” may have moved on from SolarWinds, the impact and import of the SolarWinds Orion hack are still being worked out. What were the “lessons” from SolarWinds? Beyond the 200 + organizations that were impacted by the supply chain compromise, how can private and public sector firms learn from it and become more resilient and less susceptible to the kind of attacks that hit the likes of FireEye, Qualys, Equifax and more?
To help answer those questions, the security firm ForAllSecure assembled* an all-star roundtable to tackle the question not so much of “what happened” with SolarWinds, but “how to prevent it from happening again.” I had the pleasure of moderating that discussion and I’m excited to share the video of our talk below.
I’ve included a link to our discussion below. I urge you to check it out – there are a lot of valuable insights and take aways from our panelists. In the meantime, here are a couple of my high-level take aways:
Supply Chain’s Fuzzy Borders
One of the biggest questions we wrestled with as a panel was how to define “supply chain risk” and “supply chain hacks.” It’s a harder question than you might think. Our panelists were in agreement that there was a lot of confusion in the popular and technology media about what is- and isn’t supply chain risk. Our panelists weren’t even in agreement on whether SolarWinds, itself, constituted a supply chain hack, given that the company wasn’t a supply chain partner to the victims of the attack, so much as a service provider. Regardless, there was broad agreement that the risk is real and pronounced.
“We rely on third party software and services a lot more – APIs and everything,” said Chenxi Wang. “With that, the risk from software supply chain is really more pronounced.”
“What your definition of supply chain risk depends on where you sit,” said Vincent Liu. That starts with third party or open source libraries. “If you’re a software developer your supply chain looks very different from an end user who does no software development but needs to ensure that the software you bring into an organization is secure.”
At the end of the day: getting the exact definition of “supply chain risk” is less important than understanding what the term means for your organization and – of course – making sure you’re accounting for that risk in your security planning and investment.
Third Party Code: Buggy, or Bugged?
Another big question our panel considered was who was behind supply chain attacks and who the targets were. Vincent Liu of Bishop Fox. Supply chain insecurities are deliberately introduced into software development. A different approach needs to be taken when securing against that versus traditional secure software development tools, which are about identifying flaws in the (legitimate) software development process.
The impact of a flawed open source component and a compromised one matters, even if the impact is the same. The distinction between inadvertent vulnerabilities and attacks matters, said Brumley. “You really have to tease out the question of a vulnerability and whether inserted by the attacker or just latent there,” he said. The media is more interested in the concept of a malicious actor working behind the scenes to undermine software, whereas shoddy software may be less dramatic. But both need to be addressed, he said.
Developers in the Crosshairs
Another big takeaway concerns the need for more attention within organizations to an overlooked target in supply chain attacks: the developer. “It used to be that attacks were focused on company repositories and company source code. Now they’re very focused on developer machines instead,” said Moore of Rumble. “There are a lot more phishing attacks on developers, a lot of folks scraping individual developer accounts on GitHub looking for secrets. So it’s really shifted from attacks on large corporations with centralized resources to individual developer resources.”
The days of sensitive information like credentials and API keys hiding in plain site are over. “Especially for developers, your mean time to compromise now is so fast,” said Moore.
Unfortunately, too few organizations are investing to solve that very real problem. Too many firms are continuing to direct the lion’s share of their security investment into legacy tools, technologies and capabilities. ““Tons of tooling and money has been spent in terms of things that find vulnerabilities because they can find them,” notes Liu. “But most of them don’t matter. Really spending your time on the right things rather than just doing things because you can do them is so critically important.”
Digital transformation is revolutionizing how healthcare is delivered. But a simmering dispute between a UK security researcher and a domestic healthcare non-profit suggests that the road ahead may be bumpy for both organizations embracing new software and services and for those who dare to ask questions about how that software works.
A case in point: UK-based engineer Rob Dyke has spent months caught in an expensive legal tussle with the Apperta Foundation, a UK-based clinician-led non-profit that promotes open systems and standards for digital health and social care. The dispute stems from a confidential report Dyke made to the Foundation in February after discovering that two of its public Github repositories exposed a wide range of sensitive data, including application source code, user names, passwords and API keys.
The application in question was dubbed “Apperta Portal” and was publicly accessible for two years, Dyke told Security Ledger. Dyke informed the Foundation in his initial notification that he would hold on to the data he discovered for 90 days before deleting it, as a courtesy. Dyke insists he followed Apperta’s own information security policy, with which he was familiar as a result of earlier work he had done with the organization.
Open Source vs. An Open Sorcerer
Dyke (@robdykedotcom) is a self-described “open sorcerer” with expertise in the healthcare sector. In fact, he previously worked on Apperta-funded development projects to benefit the UK’s National Health Service (NHS) and had a cordial relationship with the organization. Initially, the Foundation thanked Dyke for disclosing the vulnerability and removed the exposed public source code repositories from GitHub.
That honeymoon was short lived. On March 8, 2021, Dyke received a letter from a law firm representing Apperta Foundation that warned that he “may have committed a criminal offense under the Computer Misuse Act 1990,” a thirty-year-old U.K. computer crime law. “We understand (you) unlawfully hacked into and penetrated our client’s systems and databases and extracted, downloaded (and retain) its confidential business and financial data. You then made threats to our client…We are writing to advise you that you may have committed a criminal offence under the Computer Misuse Act 1990 and the Investigatory Powers Act 2016,” the letter read, in part. Around the same time, he was contacted by a Northumbria Police cyber investigator inquiring about a report of “Computer Misuse” from Apperta.
A Hard Pass By Law Enforcement
The legal maneuvers by Apperta prompted Dyke to go public with the dispute – though he initially declined to name the organization pursuing him – and to hire his own lawyers and to set up a GoFundMe to help offset his legal fees. In an interview with The Security Ledger, Dyke said Apperta’s aggressive actions left him little choice. “(The letter) had the word ‘unlawful’ in there, and I wasn’t about to sign anything that had said I’d committed a criminal offense,” he said.
After interviewing Dyke, law enforcement in the UK declined to pursue a criminal case against him for violating the CMA. However, the researcher’s legal travails have continued all the same.
Keen to ensure that Dyke deleted the leaked data and application code he downloaded from the organization’s public GitHub repositories, Apperta’s lawyers sent multiple emails instructing Dyke to destroy or immediately deliver the data he found from the security vulnerability; to give confirmation he had not and would not publish the data he “unlawfully extracted;” and to give another confirmation that he had not shared this data with anyone.
Dyke insists he deleted the exposed Apperta Foundation data weeks ago, soon after first being asked by the Foundation. Documents provided by Dyke that were sent to Apperta attest that he “destroyed all Apperta Foundation CIC’s data and business information in my possession, the only such relevant material having been collated in February 2021 for the purposes of my responsible disclosure of serious IT security concerns to Apperta of March 2021 (“the Responsible Disclosure Materials”).”
Not Taking ‘Yes’ For An Answer
Nevertheless, Apperta’s legal team found that Dyke’s response was “not an acceptable undertaking,” and that Dyke posed an “imminent further threat” to the organization. Months of expensive legal wrangling ensued, as Apperta sought to force Dyke to delete any and all work he had done for the organization, including code he had developed and licensed as open source. All the while, Dyke fielded correspondence that suggests Apperta was preparing to take him to court. In recent weeks, the Foundation has inquired about his solicitor and whether he would be representing himself legally. Other correspondence has inquired about the best address at which to serve him an injunction and passed along forms to submit ahead of an interim hearing before a judge.
In late April, Dyke transmitted a signed undertaking and statement to Apperta that would seem to satisfy the Foundation’s demands. But the Foundation’s actions and correspondence have him worried that it may move ahead with legal action, anyway – though he is not sure exactly what for. “I don’t understand what the legal complaint would be. Is this about the database access? Could it be related to (intellectual property)?” Dyke said he doubts Apperta is pursuing “breach of contract” because he isn’t under contract with the Foundation and -in any case – followed the organization’s responsible disclosure policy when he found the exposed data, which should shield him from legal repercussions.
In the meantime, the legal bills have grown. Dyke told The Security Ledger that his attorney’s fees in March and April totaled £20,000 and another £5,000 since – with no clear end in sight. “It is not closed. I have zero security,” Dyke wrote in a text message.
In a statement made to The Security Ledger, an Apperta Foundation spokesperson noted that, to date, it “has not issued legal proceedings against Mr. Dyke.” The Foundation said it took “immediate action” to isolate the breach and secure its systems. However, the Foundation also cast aspersions on Dyke’s claims that he was merely performing a public service in reporting the data leak to Apperta and suggested that the researcher had not been forthcoming.
“While Mr. Dyke claims to have been acting as a security researcher, it has always been our understanding that he used multiple techniques that overstepped the bounds of good faith research, and that he did so unethically.”
-Spokesperson for The Apperta Foundation
Asked directly whether The Foundation considered the legal matter closed, it did not respond, but acknowledged that “Mr. Dyke has now provided Apperta with an undertaking in relation to this matter.”
Apperta believes “our actions have been entirely fair and proportionate in the circumstances,” the spokesperson wrote.
Asked by The Security Ledger whether the Foundation had reported the breach to regulators (in the UK, the Information Commissioner’s Office is the governing body), the Foundation did not respond but said that it “has been guided by the Information Commissioner’s Office (ICO) and our legal advisers regarding our duties as a responsible organisation.”
OK, Boomer. UK’s Cyber Crime Law Shows Its Age
Dyke’s dealings with the Apperta highlights the fears that many in the UK cybersecurity community have in regards to the CMA, a 30 year-old computer crime law that critics say is showing its age.
A 2020 report from TechUK found that 80% of respondents said that they have been worried about breaking the CMA when researching vulnerabilities or investigating cyber threat actors. Also, out of those same respondents, around 40% said the law has acted as a barrier to them or their colleagues and has even prevented cybersecurity employees from proactively safeguarding against security breaches.
Those who support amending the CMA believe that the legislation poses several threats for Great Britain’s cyber and information security industry. Edward Parsons of the security firm F-Secure observed that “the CMA not only impacts our ability to defend victims, but also our competitiveness in a global market.” This downside, along with the ever-present talent shortage of cybersecurity professionals in the U.K., are reasons that Parsons believes justify a newly updated version of the CMA be passed into law.
Dyke said the CMA looms over the work of security researchers. “You have to be very careful about participating in any, even formal bug bounties (…) If someone’s data gets breached, and it comes out that I’ve reported it, I could actually be picked up under the CMA for having done that hacking in the first place,” he said.
Calls for Change
Calls for changes are growing louder in the UK. A January, 2020 report by the UK-based Criminal Law Reform Now Network (CLRNN) found that the Computer Misuse Act “has not kept pace with rapid technological change” and “requires significant reform to make it fit for the 21st century.” Among the recommendations of that report were allowances for researchers like Dyke to make “public interest defences to untie the hands of cyber threat intelligence professionals, academics and journalists to provide better protections against cyber attacks and misuse.”
For researchers like Dyke, the changes can’t come soon enough. “The Act is currently broken and disproportionately affects hackers,” he wrote in an email. He said a reformed CMA should make allowances for the kinds of “accidental discoveries” that led him to the Apperta breach. “It needs to ensure safe harbour for professional, independent security researchers making Responsible Disclosure in the public interest.”
Web sites for customers of agricultural equipment maker John Deere contained vulnerabilities that could have allowed a remote attacker to harvest sensitive information on the company’s customers including their names, physical addresses and information on the Deere equipment they own and operate.
The researcher known as “Sick Codes” (@sickcodes) published two advisories on Thursday warning about the flaws in the myjohndeere.com web site and the John Deere Operations Center web site and mobile applications. In a conversation with Security Ledger, the researcher said that a he was able to use VINs (vehicle identification numbers) taken from a farm equipment auction site to identify the name and physical address of the owner. Furthermore, a flaw in the myjohndeere.com website could allow an unauthenticated user to carry out automated attacks against the site, possibly revealing all the user accounts for that site.
Sick Codes disclosed both flaws to John Deere and also to the U.S. Government’s Cybersecurity and Infrastructure Security Agency (CISA), which monitors food and agriculture as a critical infrastructure sector. As of publication, the flaws discovered in the Operations Center have been addressed while the status of the myjohndeere.com flaws is not known.
Contacted by The Security Ledger, John Deere did not offer comment regarding the bulletins prior to publication.
Sick Codes, the researcher, said he created a free developer account with Deere and found the first myjohndeere.com vulnerability before he had even logged into the company’s web site. The two flaws he disclosed represent only an hour or two of probing the company’s website and Operations Center. He feels confident there is more to be found, including vulnerabilities affecting the hardware and software deployed inside the cabs of Deere equipment.
“You can download and upload stuff to tractors in the field from the web. That is a potential attack vector if exploitable.”
Ag Equipment Data: Fodder for Nation States
The information obtained from the John Deere websites, including customer names and addresses, could put the company afoul of data security laws like California’s CCPA or the Personal Information Protection Act in Deere’s home state of Illinois. However, the national security consequences of the company’s leaky website could be far greater. Details on what model combines and other equipment is in use on what farm could be of very high value to an attacker, including nation-states interested in disrupting U.S. agricultural production at key junctures, such as during planting or harvest time.
The consolidated nature of U.S. farming means that an attacker with knowledge of specific, Internet connected machinery in use by a small number of large-scale farming operations in the midwestern United States could launch targeted attacks on that equipment that could disrupt the entire U.S. food supply chain.
Agriculture is uniquely susceptible to such disruptions, says Molly Jahn, a Program Manager in the Defense Sciences Office at DARPA, the Defense Advanced Research Projects Agency and a researcher at the University of Wisconsin, Madison.
“Unlike many industries, there is extreme seasonality in the way John Deere’s implements are used,” Jahn told Security Ledger. “We can easily imagine timed interference with planting or harvest that could be devastating. And it wouldn’t have to persist for very long at the right time of year or during a natural disaster – a compound event.” An attack aimed at economic sabotage and carried out through combines at harvest time in the midwest it would be “devastating and unrecoverable depending on the details,” said Jahn.
However, the Agriculture sector and firms that supply it, like Deere, lag other industries in cyber security preparedness and resilience. A 2019 report released by Department of Homeland Security concluded that the “adoption of advanced precision agriculture technology and farm information management systems in the crop and livestock sectors is introducing new vulnerabilities into an industry which had previously been highly mechanical in nature.”
DHS Report: Threats to Ag Not Taken Seriously
“Most of the information management / cyber threats facing precision agriculture’s embedded and digital tools are consistent with threat vectors in all other connected industries. Malicious actors are also generally the same: data theft, stealing resources, reputation loss, destruction of equipment, or gaining an improper financial advantage over a competitor,” the report read.
The research group that prepared that report visited large farms and precision agriculture technology manufacturers “located throughout the United States.” The report concluded that “potential threats to precision agriculture were often not fully understood or were not being treated seriously enough by the front-line agriculture producers,” the report concluded.
Jahn said the U.S. agriculture sector has emphasized efficiency and cost savings over resilience. The emergence of precision agriculture in the last 15 years has driven huge increases in productivity, but also introduced new risks of disruptions that have not been accounted for.
“We have not thought about protecting the data from unwanted interference of any type,” she said. “That includes industrial espionage, sabotage or a full on attack…I have consistently maintained cyber risk on the short list of existential threats to US food and agriculture system.”
Goodness is hard to measure. More so in the field of Cybersecurity. In the physical world, if you possess something, say a $1 bill, you have it. If you spend it, you don’t have it. If someone steals it, you don’t have it, either. The digital world is quite different. Digital copies are the same as the original – exactly the same. Each replicated copy is at least as original as the original original. “Can you send me a copy?” can only be answered, “No, but I can send you an original.”
You know all that.
A non time-sensitive digital asset that could be infinitely replicated was itself of little value. It could be replicated many times and in theory “spent” many times. But of course, there were no buyers. Enter cryptocurrency, Bitcoin for an obvious example. A Bitcoin aspires to be a digital $1 bill that can neither be double-spent nor infinitely replicated. How do those two miracles occur? Blockchain.
Data’s Deep Fake Problem
What else can we do with this marvelous technology that allows us to prove in the digital world that if I have something, I really have it, and if I do not have it, I really don’t have it?
The first digital image ever created was of Russel Kirsch’s son, Walden, scanned from a photograph in 1957. (Source: Wikipedia.)
More than 60 years ago, the first digital photograph was created. Businesses missed the implication. Film-based photographs were hard to manipulate; not so digital photographs which can be easily manipulated. The implication is that the integrity of the photographic data on which a business decision was being made had very substantially degraded. And, no one seemed to notice… for a while.
When businesses did notice, they just started to drop photographs from their business processes. Rightly so. The integrity of the data was highly suspect and nowhere near the quality for a serious business decision. Enter blockchain once again. Blockchain enables the data to be “frozen” at the “moment of creation.” The integrity of the data is preserved and actionable business decisions can be made by responsible people.
How do we think about this? What is the right way to analogize what we know? For illustration and conversation, the present authors offer the table below, the Data Integrity Scale, in the hope of making levels of “goodness” contributory to decision support. Availability has metrics – downtime can easily be measured – but, until now, Integrity has not had a firm scale to measure with.
A Scale for Data Integrity
Most current systems are not designed to protect the Integrity of the data from the moment of creation until the point of use. Protect its Confidentiality? Yes. Protect its Availability? Yes, again. The more we depend on data to drive processes of increasing complexity, the more Integrity supplants Confidentiality and Availability as the paramount goal of cybersecurity.
The Cyber Integrity Question of 2021
The table attempts to correlate the measures of trustworthiness across the domains of Law, Accounting, and Business. The sort of question that jumps out from the table might be:
Since I require the proof of a person’s identity (credentialing) be above the red bar before I would let him or her act on the company’s data, why should I not also require that data be above the red bar before I allow it to act on other company data?
“Data integrity is the maintenance of, and the assurance of the accuracy and consistency of data over its entire life-cycle, and is a critical aspect to the design, implementation, and usage of any system which stores, processes, or retrieves data.” … It is at times used as a proxy term for data quality.”5
But “quality” without a way to define and measure it, is an ephemeral term. One common definition of quality is “conformance to requirements.” Here, we might require that the Integrity of data be “above the bar” on the Data Integrity Scale.
A report from Deloitte (PDF) indicates that Data Integrity violations account for over 40 percent of pharmaceutical warning letters issued globally.
The historical methods of chasing Visibility and Context through Data Governance down a long chain-of-custody/audit trail are now outdated techniques (and not very reliable in any event – too many steps along the way). A registered “record copy” via blockchain technology is a far better solution. Businesses that are assiduously checking for viruses (aka automated tampering), should also ensure the data they actually use for major decisions has Integrity and is not the result of automated or physical tampering. Blockchain technology allows photos, videos, and other data to jump “above the bar.”
Back to the Future
Roll back those 50 years – actually to 1957 – when the world encountered the first digital photograph. A person needed the skills of a professional photographer to fake a photograph. There was a general feeling of “trust” in what was depicted in a photograph. That was then and this is now, but with adroit use of blockchain technology it is once again possible to have “trust” in photographs and videos, and restore Integrity
What can you do with that “trust?” Business decision makers no longer have to deal with information along a previously believed continuum of certitude; “through a glass darkly,” but rather can see clearly the demarcations where information is useful and not useful.
The rapid digitalization of business processes has caused a greater need for accurate data as there are no longer humans further upstream in the process to keep the low-quality data from infecting the automated business decision process.
Now is the time to align the ordinal scales of jurisprudence and accounting with each other and with like-minded ordinal scales for business processes. We offer a first cut at that necessary advance; we hope that it is sufficient to purpose and self-explanatory, and will allow this advancement in technology to open new markets with innovative products.
“Beyond a Reasonable Doubt.” Whitman J. (2005) The Origins of Reasonable Doubt, Yale University Press.
“Clear and Convincing Proof.” Colorado v. New Mexico, 467 U.S. 310, 467 (1984)
“Preponderance of the evidence.” Leubsdorf J., (2015), The Surprising History of The Preponderance of the Standard of Civil Proof, 67 Fla. L. Rev. 1569
“Substantial Evidence” Richardson v. Perales, 402 U.S. 389, 401 (1971)
“Probable Cause” United States v. Clark, 638 F.3d 89, 100–05 (2d Cir. 2011)
“Reasonable Suspicion” Terry v. Ohio 392 U.S. 1 (1968)
“Mere Scintilla” Hayes v. Lucky, 33 F. Supp. 2d 987 (N.D. Ala. 1997)
“In all material respects” Materiality considerations for attestation engagements, AICPA, 2020
“Reasonable Assurance” Guide to Financial Statement Services: Compilation, Review, and Audit. AICPA. 2015 AU-C 200: Overall Objectives of the Independent Auditor. AICPA. 2015. AU-C 240: Consideration of Fraud in a Financial Statement Audit. AICPA. 2015
“Substantial Authority” “Realistic possibility “Reasonable basis” “Frivolous or Patently Improper”
Interpretations of Statement on Standards for Tax Services No. 1, Tax Return Positions, AICPA (Effective Jan. 1, 2012, updated April 30, 2018,)
NIST Special Publication 800-63 Revision 3 June 2017
Photos and Videos
“SOC2” AICPA -Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy. Updated January 1, 2018
“ISO 270001” is an international standard on how to manage information security. Revised 2013. The International Organization for Standardization is an international standard-setting body composed of representatives from various national standards organizations.
“GDPR” The General Data Protection Regulation is a regulation in EU law on data protection and privacy in the European Union and the European Economic Area. Implementation date: 25 May 2018
The information security industry is simultaneously robust and beset by problems and challenges. For one thing: attacks are proliferating and becoming more stealthy and difficult to detect. Updated virus signatures won’t do you much good these days, when attackers are infiltrating software build processes or “living off the land” using administrative tools like Powershell and WMI to do their dirty work.
Compounding that there is a talent shortage that measures in the millions of workers globally, and hundreds of thousands of workers just in the U.S. To continue to be effective, in other words, the information security industry needs both better tools to fight adversaries, and more people to do the fighting.
In this interview, Renee talks about her journey to a leadership role in information security and about how the information security can scale up to meet the challenges of the future. That means both embracing technologies like automation and machine learning to help manage the tsunami of data and threats, and broadening the avenues into information security and attracting a range of skills – both hard and soft- to the industry. We also talk about her latest project: a children’s book to educate kids about basic cyber security concepts.