
Siemens contractor pleads guilty to planting logic bomb in company spreadsheets - pjmlp
https://www.zdnet.com/article/siemens-contractor-pleads-guilty-to-planting-logic-bomb-in-company-spreadsheets/
======
CPLX
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.

~~~
jsty
IANAL

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.

~~~
SkyBelow
> 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).

------
quietbritishjim
> 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).

------
pavel_lishin
> _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

~~~
DataWorker
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.

------
zer0faith
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.

~~~
danso
Excel is/was a popular tool at the highest level in various industries,
including finance. A frequently shared anecdote:

[https://baselinescenario.com/2013/02/09/the-importance-of-
ex...](https://baselinescenario.com/2013/02/09/the-importance-of-excel/)

> _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... _

~~~
alexpotato
That's why this is such a great article: Manual Work is a Bug
([https://queue.acm.org/detail.cfm?id=3197520](https://queue.acm.org/detail.cfm?id=3197520))

It creates the mindset of, let me do a little everyday to make this a more
automated process.

~~~
froindt
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.

~~~
danso
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).

[0]
[https://csvkit.readthedocs.io/en/1.0.3/scripts/in2csv.html](https://csvkit.readthedocs.io/en/1.0.3/scripts/in2csv.html)

[1]
[https://csvkit.readthedocs.io/en/1.0.3/scripts/csvsql.html](https://csvkit.readthedocs.io/en/1.0.3/scripts/csvsql.html)

------
ma2rten
_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.

~~~
SmellyGeekBoy
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.

~~~
user5994461
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.

------
ga-vu
This.. does not seem like an optimal way to run a business on Siemens' part.
What happened if this guy got hit by a bus?

------
logfromblammo
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".

------
empath75
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.

~~~
tantalor
It's a intentional failure designed to trigger after a certain amount of
time... sounds like a "bomb" to me.

~~~
Timpy
Sounds like "Apple's business model" to me

------
radcon
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.

~~~
rtkwe
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.

------
jshowa3
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.

~~~
crispyporkbites
I'll go on the record here and say that this exact comment will remain
appropriate and relevant in 2029 and possibly still in 2039

~~~
jshowa3
Yup, crap software practices stick around for a long time. Which is why lack
of standards is frustrating and we'll never learn from mistakes.

------
thomc
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.

~~~
marktangotango
Lol I haven't heard "abend" in years, thanks for the flashback!

------
oneepic
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)

------
yadaeno
You would think he would make sure to be home when his logic bomb was set to
go off.

------
durnygbur
Crucial business stuff in a spreadsheet (let me guess, Visual Basic?) secured
with a shared password (let me guess, over plain text email?).

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.

~~~
cb504
This guy isn't a scapegoat.

Managers might be negligent, but he is still responsible for his illegal
actions.

------
peanutgal2600
This doesn't seem much different than planned obsolescence to be honest.

If he had done this to 100 companies, then he would be considered an
enterprise, not a criminal.

~~~
raxxorrax
Sometimes it is also called SaaS.

------
__saykou
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.

~~~
pedrocr
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.

~~~
lolc
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.

~~~
AnIdiotOnTheNet
"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.

------
needsMoreCDKEYS
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?

~~~
CPLX
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.

~~~
jshowa3
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.

