The next time anyone tells you that they have built a „Secure“ system, get them to read this article.
Source: BAE Systems Threat Research Blog: Two bytes to $951m
An unknown number of people with a lot of easily acquired knowledge, but not so common skills, developed and deployed a system of hacks to manipulate a „secure“ banking system to transfer almost a billion dollars to accounts unknown. A large amount of this money is now „accounted for“, whatever that means, while 81 Million Dollars are still missing. That looks like a pretty good return on investment if you’re not too worried about illegalities or you consider it just liberating the money from robber banks.
Of course, many will say „our security standards are better than those in Bangladesh“ but those people are just trying to reassure those who cannot, for whatever reason, understand the signals generated by this particular case.
An incredible number of systems rely on the key system-parts misused in this hack. I would not have believed it until I saw it, so many systems rely on reading and writing text files from some location, often a network share, and these files are easily manipulated if due attention is not paid to the security of those files.
Just last week I had an application development team who could not, or would not because of time constraints, understand why it was a bad idea to let a server inside the secure zone reach out to a server on the internet in order to automatically download some code. The number of ways in which their deployment scheme could be hacked into and misused was mind-boggling and yet, they considered it not only safe, but also perfectly normal. Someone is going to make a lot of money out of their overly relaxed attitude if they should draw the wrong kind of attention.
So, I came out of a meeting this morning where there was a large amount of ITIL type talk about „Tickets“, „Incidents“, „Changes“, „Emergency Changes“, and whether an Incident was documentation enough to mean not having to also create a(n emergency) Change Request“.
I went to the Ceramic Department afterwards and there I heard that Günther Grass had died so I started to wonder whether the grim Reaper did his job driven by „incidents“ (someone died, go deal with it) or „Changes“ (someone’s time has come, go and change the state from living to dead.) This led me to wonder, if, just if, this was a „change request“ scenario, whether that would require someone/-thing to approve the change and whether with an appropriate Lobby the Change could be rejected. I was left with a profound feeling of, well, if there is an afterlife, they’d better have their ITIL stuff together, because otherwise I’m going to get some relevant, inadequately documented, „changes“ revoked. Maybe starting with John Lennon’s shooting.
Anybody doing SQL Server service providing will have uttered this phrase at least once in their professional carreer. This piece provides some anyalyis of the reasons.
Naming conventions are poison. | Facility9.
In this article Jeremiah Peschka speaks from my heart. One day I hope naming conventions are going to go the way of … well … one of those things that went obsolete because technology moved ahead. (As a shining example, the A20 gate in x86 Processors. This was a hack when first introduced but it was a hack that stuck.) The rest of the computing environment changed so much that the A20 Gate became more trouble than it was worth. That’s how I feel abut naming conventions, causing more trouble than they are worth because the tools do a much better job of telling us what something is than messing with the name ever could.
I can, through my current work, now add some new hated naming conventions to my growing list. This one’s not a full grown hate, more an annoyance, but I don’t like naming an instance according to the version of SQL Server running it. It becomes tedious for everyone come the day that the old version is end-of-lifecycle.