Thursday, February 28, 2013
Wednesday, February 27, 2013
“C lacks good memory management”. Really? C’s memory management is basically an extension of the OS exposed memory management and is many cases is modeled after POSIX which is includes various standards and expected behaviors. And let’s not forget that many high level languages and libraries are themselves written or descended from C.
"If we could start over" is a very common battle cry. WTF are these managers and architects thinking about? What they seem to be suggesting is that the well trodden path that they are collectively exploring is no longer any good and they need to try the other fork in the road. The for where they have no real professional experience and where all the problems they have already solved need to be discarded for a whole new bread of problems. And like the conversion from COBOL to C, mainframes to PCs, the transition is going to have it's casualties... and believe it or not there are still plenty of COBOL/JCL mainframes out there.
To those US executives that support the code.org movement. Before you dilute yet another US industry you better plan for what's going to happen here. No presidential stimulus is going to help you sell your tech and services if more is not designed, manufactured and built in the US.
Tuesday, February 26, 2013
Monday, February 25, 2013
Warning is post is part fiction and part stream of consciousness and my intent is to take you to a happy place or give you a lot more to think about.
WildCard the early days:
- one of the interesting things that happened to us was the day the very first BIN went live (processing through FDR in Omaha). Even before the first card was manufactured we started receiving transactions from Nigeria. They were clearly bogus but we were not expecting anything at all.
- years later I caught our first ATM bandits in Moscow. (a) they ran too many PIN transaction in such a short period of time that they could only have accomplished this with a hijacked ATM (b) somehow they knew we did some sort of load balancing so they were trying to skim a little off the top.
- we did have a programmer of Russian origin that worked for WildCard; he was later laid off when WildCard downsized after it's own first bubble burst. In retrospect he was always working odd hours; his explanation was so that he could VOIP home to Russia.
- WildCard, later eFunds and now FIS; outsources a lot of it's software development. With any luck they review each and every line of code but not likely. The thing is; a C-level executive was so focused on outsourcing that there was a swell of offshore, on site, developers. Dev went from 100 to 500 in a matter of months. It is my understanding that they were all foreign contractors.(Courtesy of Bill Gates)
The FIS attack:
- I'm surprised that they got in. I know the guy who designed the network and I know he was also one of the most highly certified Cisco tech there was. Even at WildCard there were layers upon layers of network infrastructure. Production was locked off from everything else. Machines inside the firewall were not supposed to be able to make connections to systems outside the firewall. And so on. It was tighter than Fort Knox.
- the authorization system is even more self contained. In fact the auth system is almost a network unto itself. Therefore, the only thing they could have done was attack the backoffice system. That system was originally build with VB and then moved to coldfusion and then there was a sharepoint implementation and later MS business object or something like that. The thing is; WildCard was very aware of things like SQL injection and API permissions and such. So unless intentional or unintentional bug in the system... this was not an attach vector either.
- one thing for certain. The users were not going to gain access from the network. Even if the card programs were accessible to product managers through the public internet.
- the API layer was going to require passwords and some encryption if they planned to gain access through the APIs. And even then they'd need the API docs and credentials.
- If they managed to log into production they'd have to make it through many layers of security in order to make it to the DB. And even with a TSQL command shell you'd need credentials.
But wait there's more.
- once they logged into the DB you'd have to know which table to change... of some 300 to 500 tables.
- but once they had the right table they'd need to know which card program was assigned to so they could update the velocity check.
(a) this was very likely an inside job and might have been a sleeper for years)
(b) when you're a small company you better trust your employees beyond the usual resume screening.
(c) you might be better off hiring a real security firm for recommendations.
I just watched a video segment about espionage and counter espionage. It's interesting that spies do not always do the dirty work. They hire "cut outs" to do it for them. Sadly this could be anyone and of course the consequences are not less devastating.
I read another article "what would happen if everything you knew was false" or something like that. Basically a West German police man killed a protestor in 1957. At the time he said he was threatened or some such. After a brief suspension he returned to work and was later promoted. Fast forward to present day and it turns out this guy was a spy for the Stassi (East German Secret Service).
** So how do we remain secure? Good question.
- know your hardware
- know your network
- know your infrastructure
- know your physical security
- know your operating system
- know your tools
- know your employees
- know your programmers, testers, etc
- know your process
- know all your 3rd parties
It comes down to full stack awareness... the stack happens to be much bigger than once thought.
Sunday, February 24, 2013
PS: The same can be said for GO.
NodeJS in the form of ExpressJS is getting some of my mindshare. My only concern is that amount of dependencies there are to accomplish the most basic tasks. And then... when you actually create a package or push your code to production... there is so much of it.
I know there are a lot of people that like version 2 of stuff... ie; Perl 6, Python 3 and not Ruby 2. It seems to me that in today's environment version X+1 should be less and not more. Or at least do more with less. I'd be impressed if they reduced the LOC footprint and didn't lose any functionality or maybe lost the bits that cause the most problems.
Friday, February 22, 2013
Thursday, February 21, 2013
Tuesday, February 19, 2013
For all the bashing I do on NodeJS I have a use-case that it might be ideally suited for. Sitting immediately behind a load-balanced webserver converting REST calls into a MQ request/response. Authenticating, parsing, and validating input before reformatting for consumption by the MQ.
Thursday, February 14, 2013
One of the hallmarks of a good open source project is just how complicated it is to install, configure and maintain. Happily gitlab and the ...
CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $...
[updated 2011.09.30] yet another response to Agile is good. When you have so much of you career invested in something like Agile, XP etc... ...
I have not had success with the touch drivers as yet. The touch works and evtest also seems to report events, however, I have noticed that ...