wait a second Siemens made a deal to have some software running inside their infrastructure without having the code open right away, that is a major rookie mistake.
well, companies do it all the time when they buy “enterprise” packages. I believe SAP is closed source and it’s the life and blood of most companies’ IT infrastructure.
Given that this was a spreadsheet it's more likely that someone hired the contractor directly without going through IT. When things were burning and IT was begrudgingly brought in to fix things they weren't predisposed to be kind. No rookies involved. Just the normal corporate IT dynamic where things move too slow so get hacked around with Excel and other kludges and everything works until it doesn't.
The article says that the spreadsheets were protected by a password that the contractor did not initially hand over. So yes, that was a oversight of Siemens.
"Protected" office documents are the rough equivalent of putting up a 'Do Not Enter' sign and are just as trivial to bypass. If anyone had really cared enough to want to see the code, they could have.
the scheme fell apart when Tinley was out of town, and had to hand over an administrative password for the spreadsheets to Siemens' IT staff, so they could fix the buggy scripts
This is like the story of the accountant who never goes on vacation, but when she finally does it turns out she had been skimming money.
I’m wondering how he got that deal past IT. Perhaps he claimed that he was licensing the code to them so that they couldn’t see it?
I’m not familiar with how to deploy Excel macros, could this code be checked into a source repo and then somehow automatically deployed? If not I can see how he can sneak this by IT by saving it was hard to deploy and that’s why I’m giving you a binary and tell all your users to hit this URL to install.
.xlsx ("normal files") and .xlsm (macro-enabled files) are a series of xml files and folders stored as a zip file with their own extension. .xlsb files are binary files, typically about 1/6 the size, and also have support of macros.
Unfortunately, regardless of save format, the VBA portion is saved in a binary format.
There are some source control systems out there for the embedded VBA code, but I haven't tried any out.
I agree. Just this morning I messed up and saved over a spreadsheet I didn't mean to...no way to get that 30 minutes of work back.
Probably 90% of my day is jumping between spreadsheets and queries building tools and updating reports. Spreadsheets are a "universal language" that most people understand, and allow the technically inclined business user to investigate problems without having to submit a help desk ticket and wait 4-48 hours for an answer.
In finance it is mandatory for large percentages of workers to take consecutive vacation days, one week for junior employees and two for mid level and up, for this reason.
My company does contract work for a big corporate and in my case they don't generally want access to the code - they'd rather just call me up when there's a problem as I'm not unreasonable with fees, generally available, and I know my work inside and out.
Of course if I'm away and there's an emergency they have everything they need to modify it themselves, including the in-house skills. I wouldn't do anything nefarious like this, but I can relate to the situation of them not wanting/needing day-to-day access to the code.
From the bit of time I did consulting or having to take over the previous consultant work, it's amazing how many companies just don't bother to save the source code, let alone a build script or a start script. They couldn't care less about the software that was produced, they're buying butts in seats.
I guess the right way to do this is to setup something to 'auto-install updates' which prompts a call to the contractor to fix the corrupted excel file.
> Tinley's chances for a no prison sentence are slim. In 2006, a former UBS PaineWebber worker was sentenced to eight years in prison for planting a logic bomb on the company's network and betting its stock would go down.
I don't know if the courts will see it the same way, but to me it seems that Tinley's crime is a lot less severe. That other case was stock manipulation, which has the potential to cause much larger losses for other uninvolved parties. The only effects of Tinley's action is stealing his fee directly from Siemens plus whatever loss results from the spreadsheets briefly not working (which couldn't have been that great if they didn't just get them rewritten).
It's pretty pathetic that a company is leaning on spreadsheets to survive. If your company is so terrible that it can't transcribe old printed out copies of spreadsheets, and has to subsist on formulas created by some "MS Office Guru" working a night job, then your dependency is your fault.
How is this not simply ad-hoc DRM by another name?
What's the difference between an expiring file format and Microsoft's operating system being shipped with vulnerabilities that require automatic update patches and refusing support for old versions of XP?
I’ll give you a dollar if you can name a major company that could survive more than an hour if it woke up and found out all its spreadsheets had been deleted.
There's probably a lot of them. But it's mostly due to ignorance and lack of trying other avenues. It's very easy for companies to manage orders and inventory in actual systems designed for the task in this day and age. Ones that provide an actual web interface that's accessible anywhere and generate data from a database.
Even back when I learned COBOL there were stories of programmers who intentionally created Abends so an operator would call them up with an error code, they tell them to hit enter, program resumes and they can claim callout pay.
If this spreadsheet had this type of business impact why was it in excel in the first place? Where was the version control? Why did a contractor have administrative password to such a heavily business dependent process?
This article speaks volumes about their internal IT Governance and process.
> JPMorgan’s Chief Investment Office needed a new value-at-risk (VaR) model for the synthetic credit portfolio (the one that blew up) and assigned a quantitative whiz (“a London-based quantitative expert, mathematician and model developer” who previously worked at a company that built analytical models) to create it. The new model “operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another.” The internal Model Review Group identified this problem as well as a few others, but approved the model, while saying that it should be automated and another significant flaw should be fixed.* After the London Whale trade blew up, the Model Review Group discovered that the model had not been automated and found several other errors...
I did this when I started my first full time role out of college with great success. I was responsible for tons of reports that were manual and tedious. My goal was to improve something about the process every time I did the report. It could be as little as making the label I looked for bold, or as big as refactoring and automating the entire thing. In the same way, I made standard work improvements.
That turned ~4 hrs/day of reports into an automated system, gave me a good understanding of how the various systems and reports work together, and helped me get my first promotion.
I've moved on to a new role where I'm doing the same thing on a process which has been void of substantial improvements for 3+ years. There's always something, and I can remove a bit more time with every automation iteration.
When I was working in academia, early on I decided I would finally buckle down and learn proper devops and scripting (e.g. how to do things at the command-line) and had the luxury of having all the time I wanted to bikeshed on automating the collation process (never did master Make syntax though!).
The csvkit toolset – particularly `in2csv` [0] and `csvsql`, which, respectively, can be used to extract CSV from Excel sheets and import/insert directly into sqlite – make frequent appearances in my daily work these days.
Though admittedly, I don't know what options there are to distangle spreadsheets that aren't just data (e.g. intertwined formulas).
Work in fields like healthcare, governmemt, finance, law or defense and you will see Excel spreadsheets are used for just about everything. They are simple to create, simple to use and offer very advanced controls for a fraction of the time and cost it requires to development a sufficient framework for the data in-house or configure an existing solution.
It is very easy to train people on how to use excel if they are willing to invest the time to learn formulas, and once you learn VB, you will be tempted to do most data presentation in Excel.
That said, just because most people know how to use Excel does not mean they are technically capable of setting up things like version control, backups, validation or security. A lot of users I have worked with in addition get their files from someone else, who may not even work at the company anymore and they have no idea what is or could be running in the background or how exactly the calculation in certain cells is done. Further, it is very common that one technically capable person creates an excel that becomes a crux of an internal process simply because it is the easiest thing to use, once IT governence policies are put in place, it doesn't help because they damage lies in the fundamental data they started with.
Tl;dr it is more common and innocent than it seems.
Powerpoint. I feel like I've only scratched the surface of Excel and it's definitely the most interesting part of Office software. You can do pretty much anything, and it's amazing. I've seen PDFs imitated for stuff like D&D Character Sheets, where all the cells are formatted and colored to provide whitespace around the actual fields.
The whole point of a spreadsheet is that it's a programming environment outside the control of IT processes and governance. If you don't want people to have that, don't ship Excel to their machines. (But good luck to any CIO who tries that).
Calling this a logic ‘bomb’ seems kind of silly and designed to make it sound worse than it is. Looks like he put a time lock on it or something to guarantee that they’d have to call him every once in a while. It’s absurd that they let him leave a password on the files after he left the company.
I'm surprised to see this is a prison term kind of situation.
We're talking about the choice of an algorithm in a spreadsheet delivered by a contractor being a criminal offense. It's not like that's impossible but it seems a lot more like a contractual issue at first glance. I mean fundamentally it's a string of ones and zeros, it's a piece of software.
What if he says that it was his policy to put an expiration into all his software deliverables? How is this, as a criminal legal matter different from a company that disables a piece of software without a support contract in place, or similar?
It seems a lot like a contractual issue, a discrepancy between what he delivered and what they expected, with monetary damages as the legal remedy. What am I missing here?
EDIT: Upon reading a little more about it it's a Federal charge, which seems even more insane. I can't find the actual complaint to see if it's a CFAA charge but it looks that way.
This looks a lot like yet another case of "person vs. giant multinational billion plus dollar company" on a computer issue, which means massive Federal charges for some reason, along the lines of Sergey Aleynikov, Aaron Schwartz, or Weev.
> What if he says that it was his policy to put an expiration into all his software deliverables?
If he says that in his contract, and the expiration process is written to do something honest like pop up a dialog saying "you need to renew your license" then I can't see there being a problem with that.
It sounds like there was malicious intent, however, if the contract didn't specify expiration and the expiration is intentionally designed to look like a fault rather than an expiration.
Of course multi-million dollar companies do at times get away with built-in obsolescence... be great if this set a precedent regarding all the smartphones that mysteriously become unusable after 2 years...
It looks like he was hired as a contractor to work on their internal systems (i.e. the spreadsheet) rather than licensing a product to them. If as is likely the bank owned the spreadsheet, he's purposefully modified it without permission to malfunction after a certain date - that's why it would be a criminal matter, he's been told "you can access these internal systems to incorporate functionality x", and has additionally gone in and planted malicious functionality.
When you license software that disables functionality without a current license, it's legal because you have no right to use that software without the license. If you own the copyright to some software and someone you'd hired to work on it goes and sneaks in a logic bomb to make themselves indispensable, I think you have every right to be pretty peeved.
> the bank owned the spreadsheet, he's purposefully modified it without permission to malfunction after a certain date - that's why it would be a criminal matter
> he's purposefully modified it without permission to malfunction after a certain date - that's why it would be a criminal matter
It is more than that. He purposefully modified it to expire in a time frame and in a method other developers would fine unreasonable and did so for personal profits. Then he took advantage of that modification.
Most the software I make has a problem in it when we reach the year 10,000AD. But we would all agree that is a reasonable issue that I shouldn't be found liable (it would be a massive achievement to even be remembered as a footnote come 10,000AD).
> We're talking about the choice of an algorithm in a spreadsheet delivered by a contractor being a criminal offense. ... I mean fundamentally it's a string of ones and zeros, it's a piece of software.
You can reduce anything like that. Shooting a person? How can that be a crime? Fundamentally, it's just atoms. How can atoms be illegal? All they've done is move them from one place to another.
Have federal prosecutors filed any CFAA complaints on behalf of individual consumers. For example someone who has lost over $5K in one year as a result of planned obsolescence.
I've worked with a lot of people who could be charged with creating logic bombs in everything they touch. I guess the difference is they were creating them out of ignorance. But the end result was the same, since the company would begin to see them as a necessary resource.
In this case is that he bet that the company's stocks would go down when his bomb went off.
He's not the last person who will realize that the market can be manipulated by sabotage. It seems important that the penalties for trying that outweigh the potential benefits.
> We're talking about the choice of an algorithm in a spreadsheet delivered by a contractor being a criminal offense. It's not like that's impossible but it seems a lot more like a contractual issue at first glance. I mean fundamentally it's a string of ones and zeros, it's a piece of software.
That's not what we're really talking about. He intentionally added in a failure to the software he delivered and then charged them to 'fix' the issue i.e. reset the trigger to happen at a later date and charged them for the 'fix'. Seems like a pretty straight forward fraud charge.
> But while Tinley's files worked for years, they started malfunctioning around 2014. According to court documents, Tinley planted so-called "logic bombs" that would trigger after a certain date, and crash the files.
> Every time the scripts would crash, Siemens would call Tinley, who'd fix the files for a fee.
I wonder what the code looked like. Is it obviously nefarious, like
if (date() > '2018-01-01') { exit(); }
or can it be chalked up to laziness, like
for(date in range('2000-01-01', '2018-12-31')) { process(date); // TODO, this should be moved out of this spreadsheet
They don’t like to include meaningful details like that because they are likely exculpatory. Much better to use loaded and meaningless terms like “logic bomb”. People already hate and distrust programmers, programmers who “plant bombs” makes for good prosecutorial business.
Sounds a lot like a software license with an expiration date.
I guess the main difference is that corporations have the leverage to force consumers (or employees) to accept their license terms no matter how lopsided they are, whereas the opposite is never true and so this surreptitious method was required.
If he included the timeout in his contract this wouldn't be a case and the comparison would be true. Instead what was happening was the 'logic bomb' would trigger and suddenly the sheet would be buggy, he would be called to fix the bug, change the trigger to a later date and charge the company saying he fixed it.
My question is, why is Siemens using spreadsheets and macros to manage equipment?
This, in my opinion, is a real problem. There's too much patch work trying to generate spreadsheets from other documents through macros and it's most likely a security risk.
I worked for a company that was moving away from using Office products for report management for this very reason. We have databases and it's 2019.
In fact, there's entire services that track assets already built that are infinitely better than spreadsheet generation.
Wish we had more info. I could see a scenario where he actually meant to do this with good intentions, not malicious ones. Maybe he had some information like, the spreadsheet data would be WAY out of date and cause issues every couple of years (just a contrived example). In that case, he would have to fix it anyway. But still that would beg the question, why didn't he tell IT/management?
I think ten years is way too much. Maybe like 3-5 if he had malicious intent. (not a lawyer)
There will always be business managers that put their company's crown jewels into a complex spreadsheet managed by an amateur or semi-pro. With millions of dollars flowing through the pipes surrounding them, they will make ignorant technical decisions just to save $1000.
It's analogous to being able to hire a full-time personal physician, and then self-diagnosing all your medical problems with quartz crystals and pendulums, and not even the free and reputable medical information sources.
We routinely give out free advice, such as:
- Make backups.
- ...including an off-site backup.
- Use source control.
- Don't trust inputs.
- Run tests.
Maybe we can add to this, "if your company has permanent in-house developers, use them" and "synchronize your personal calendar with your logic bomb schedule".
76 comments
[ 4.7 ms ] story [ 147 ms ] threadThis is like the story of the accountant who never goes on vacation, but when she finally does it turns out she had been skimming money.
I’m not familiar with how to deploy Excel macros, could this code be checked into a source repo and then somehow automatically deployed? If not I can see how he can sneak this by IT by saving it was hard to deploy and that’s why I’m giving you a binary and tell all your users to hit this URL to install.
Unfortunately, regardless of save format, the VBA portion is saved in a binary format.
There are some source control systems out there for the embedded VBA code, but I haven't tried any out.
Probably 90% of my day is jumping between spreadsheets and queries building tools and updating reports. Spreadsheets are a "universal language" that most people understand, and allow the technically inclined business user to investigate problems without having to submit a help desk ticket and wait 4-48 hours for an answer.
Of course if I'm away and there's an emergency they have everything they need to modify it themselves, including the in-house skills. I wouldn't do anything nefarious like this, but I can relate to the situation of them not wanting/needing day-to-day access to the code.
If he had done this to 100 companies, then he would be considered an enterprise, not a criminal.
I don't know if the courts will see it the same way, but to me it seems that Tinley's crime is a lot less severe. That other case was stock manipulation, which has the potential to cause much larger losses for other uninvolved parties. The only effects of Tinley's action is stealing his fee directly from Siemens plus whatever loss results from the spreadsheets briefly not working (which couldn't have been that great if they didn't just get them rewritten).
How is this not simply ad-hoc DRM by another name?
What's the difference between an expiring file format and Microsoft's operating system being shipped with vulnerabilities that require automatic update patches and refusing support for old versions of XP?
In my experience pretty much every company on the planet would be deemed "pretty pathetic" by your lofty standards.
This article speaks volumes about their internal IT Governance and process.
You'd be surprised.
Excel files are used to handle trillions (not billions) of dollars in businesses, even for the most critical processes...
https://baselinescenario.com/2013/02/09/the-importance-of-ex...
> JPMorgan’s Chief Investment Office needed a new value-at-risk (VaR) model for the synthetic credit portfolio (the one that blew up) and assigned a quantitative whiz (“a London-based quantitative expert, mathematician and model developer” who previously worked at a company that built analytical models) to create it. The new model “operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another.” The internal Model Review Group identified this problem as well as a few others, but approved the model, while saying that it should be automated and another significant flaw should be fixed.* After the London Whale trade blew up, the Model Review Group discovered that the model had not been automated and found several other errors...
It creates the mindset of, let me do a little everyday to make this a more automated process.
That turned ~4 hrs/day of reports into an automated system, gave me a good understanding of how the various systems and reports work together, and helped me get my first promotion.
I've moved on to a new role where I'm doing the same thing on a process which has been void of substantial improvements for 3+ years. There's always something, and I can remove a bit more time with every automation iteration.
The csvkit toolset – particularly `in2csv` [0] and `csvsql`, which, respectively, can be used to extract CSV from Excel sheets and import/insert directly into sqlite – make frequent appearances in my daily work these days.
Though admittedly, I don't know what options there are to distangle spreadsheets that aren't just data (e.g. intertwined formulas).
[0] https://csvkit.readthedocs.io/en/1.0.3/scripts/in2csv.html
[1] https://csvkit.readthedocs.io/en/1.0.3/scripts/csvsql.html
It is very easy to train people on how to use excel if they are willing to invest the time to learn formulas, and once you learn VB, you will be tempted to do most data presentation in Excel.
That said, just because most people know how to use Excel does not mean they are technically capable of setting up things like version control, backups, validation or security. A lot of users I have worked with in addition get their files from someone else, who may not even work at the company anymore and they have no idea what is or could be running in the background or how exactly the calculation in certain cells is done. Further, it is very common that one technically capable person creates an excel that becomes a crux of an internal process simply because it is the easiest thing to use, once IT governence policies are put in place, it doesn't help because they damage lies in the fundamental data they started with.
Tl;dr it is more common and innocent than it seems.
I think that the persons who need attention are the managers who let things like this to happen, not the contractors who they hire as scapegoats.
Managers might be negligent, but he is still responsible for his illegal actions.
We're talking about the choice of an algorithm in a spreadsheet delivered by a contractor being a criminal offense. It's not like that's impossible but it seems a lot more like a contractual issue at first glance. I mean fundamentally it's a string of ones and zeros, it's a piece of software.
What if he says that it was his policy to put an expiration into all his software deliverables? How is this, as a criminal legal matter different from a company that disables a piece of software without a support contract in place, or similar?
It seems a lot like a contractual issue, a discrepancy between what he delivered and what they expected, with monetary damages as the legal remedy. What am I missing here?
EDIT: Upon reading a little more about it it's a Federal charge, which seems even more insane. I can't find the actual complaint to see if it's a CFAA charge but it looks that way.
This looks a lot like yet another case of "person vs. giant multinational billion plus dollar company" on a computer issue, which means massive Federal charges for some reason, along the lines of Sergey Aleynikov, Aaron Schwartz, or Weev.
If he says that in his contract, and the expiration process is written to do something honest like pop up a dialog saying "you need to renew your license" then I can't see there being a problem with that.
It sounds like there was malicious intent, however, if the contract didn't specify expiration and the expiration is intentionally designed to look like a fault rather than an expiration.
Of course multi-million dollar companies do at times get away with built-in obsolescence... be great if this set a precedent regarding all the smartphones that mysteriously become unusable after 2 years...
It looks like he was hired as a contractor to work on their internal systems (i.e. the spreadsheet) rather than licensing a product to them. If as is likely the bank owned the spreadsheet, he's purposefully modified it without permission to malfunction after a certain date - that's why it would be a criminal matter, he's been told "you can access these internal systems to incorporate functionality x", and has additionally gone in and planted malicious functionality.
When you license software that disables functionality without a current license, it's legal because you have no right to use that software without the license. If you own the copyright to some software and someone you'd hired to work on it goes and sneaks in a logic bomb to make themselves indispensable, I think you have every right to be pretty peeved.
Indeed. That's an excellent point, if true.
It is more than that. He purposefully modified it to expire in a time frame and in a method other developers would fine unreasonable and did so for personal profits. Then he took advantage of that modification.
Most the software I make has a problem in it when we reach the year 10,000AD. But we would all agree that is a reasonable issue that I shouldn't be found liable (it would be a massive achievement to even be remembered as a footnote come 10,000AD).
In fact it was CFAA: 18 USC § 1030.
> The case is U.S. v. Tinley, case number 2:19-cr-00156, in the U.S. District Court for the Western District of Pennsylvania.
[1] https://www.law360.com/commercialcontracts/articles/1180318/...
You can reduce anything like that. Shooting a person? How can that be a crime? Fundamentally, it's just atoms. How can atoms be illegal? All they've done is move them from one place to another.
Outcomes are what matter.
More specifically, intent.
https://regmedia.co.uk/2019/06/25/tinley-siemens-logic-bomb....
Have federal prosecutors filed any CFAA complaints on behalf of individual consumers. For example someone who has lost over $5K in one year as a result of planned obsolescence.
https://en.wikipedia.org/wiki/Planned_obsolescence
He's not the last person who will realize that the market can be manipulated by sabotage. It seems important that the penalties for trying that outweigh the potential benefits.
Do you apply that same logic to other software, such as Malware?
That's not what we're really talking about. He intentionally added in a failure to the software he delivered and then charged them to 'fix' the issue i.e. reset the trigger to happen at a later date and charged them for the 'fix'. Seems like a pretty straight forward fraud charge.
> Every time the scripts would crash, Siemens would call Tinley, who'd fix the files for a fee.
I wonder what the code looked like. Is it obviously nefarious, like
or can it be chalked up to laziness, likeI guess the main difference is that corporations have the leverage to force consumers (or employees) to accept their license terms no matter how lopsided they are, whereas the opposite is never true and so this surreptitious method was required.
This, in my opinion, is a real problem. There's too much patch work trying to generate spreadsheets from other documents through macros and it's most likely a security risk.
I worked for a company that was moving away from using Office products for report management for this very reason. We have databases and it's 2019.
In fact, there's entire services that track assets already built that are infinitely better than spreadsheet generation.
I think ten years is way too much. Maybe like 3-5 if he had malicious intent. (not a lawyer)
It's analogous to being able to hire a full-time personal physician, and then self-diagnosing all your medical problems with quartz crystals and pendulums, and not even the free and reputable medical information sources.
We routinely give out free advice, such as:
Maybe we can add to this, "if your company has permanent in-house developers, use them" and "synchronize your personal calendar with your logic bomb schedule".