It’s been a while since I’ve blogged on a security topic, but this one caught my eye today: researchers in Germany have revealed an intriguing new ATM exploit. In the past I’ve written about skimmers, devices installed on ATMs to steal card codes from ATM cards. Now thieves are targeting the ATMs directly, instead of user accounts.
…hackers have to physically cut holes into ATMs, then plug in USB drives that install code onto the cash dispenser.
Once the exploit has been installed, the attacker types in a 12-digit access code, selects the denominations to dispense, and voila! Payday! There’s even a non-collusion mechanism built in:
…the criminal at the cash point had to call another gang member for a numerical code to input before they could grab the bank notes.
Obviously, this sort of exploit would have to be targeted specifically at a particular ATM maker, maybe at a given software release, and perhaps even at a particular bank, if the bank was to customize the ATM code at all.
Still, somehow I feel safer that it’s not my bank account that’s being attacked, it’s the ATM itself. At least I don’t have to explain why my card and code were used, when in fact they were stolen.
I’ve covered a number of basic agile concepts over the last few weeks, and I think it’s time to start to talk about some of the more complicated ones. This week, it’s time to talk about failure, and why you should fail fast. Read more
Posted February 28, 2013 by Keith McMillan | Leave a Comment
This week, we’re going to take a look at retrospectives. The principles behind the manifesto include “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behavior accordingly”. The most common way this is done is the retrospective. Read more
Posted January 14, 2013 by Keith McMillan | Leave a Comment
Continuing the theme from last week, where we discussed some of the principles behind the manifesto, this week’s concept is technical excellence. The principles say “Continuous attention to technical excellence and good design enhances agility”. Why should that be so? Can’t we just add quality in later? Read more
Posted January 7, 2013 by Keith McMillan | Leave a Comment
The Principles Behind the Agile Manifesto includes among it’s many good ideas the following: Simplicity – the art of maximizing the amount of work not done – is essential. What’s that about, then? Read more
Agile practitioners like to use lightweight project management approaches. We still need a way to keep track of what needs to happen, even if we don’t use a Microsoft Project plan. One approach, favored by Scrum practitioners, is the backlog. So what’s a backlog? Is there more than one type? And what goes in them? Read more
When folks set out to estimate the amount of work they have to do for a particular user story (what’s a user story? that’s another post…), they have to decide how they’re going to estimate the level of effort. There are two popular ways to estimate user stories: ideal hours (if you did nothing else but this task) and story points. What’s the difference, and which should you choose? Read more
Posted December 13, 2012 by Keith McMillan | Leave a Comment
I thought it would be interesting to start a series on agile concepts, giving a simple definition (or at least as good as can manage) and some examples. I decided to start with the Cone of Certainty. Read more
One of the fundamental tools in a Scrum project is the retrospective, the regular meeting at which the team looks at what they’ve been doing, and thinks about ways to improve. To my way of thinking, it’s sort of like the project post mortems we used to have, only better. But not all retrospectives are created equal. Read more
I sometimes wonder about whether large companies can be agile. When I think about how a company grows organically, one of the first things that seems reasonable is that as you add more testers, for example, you hire a testing manager, and they have their own group. The same applies to database administrators, business analysts and the like, and you arrive at something that looks very like the average modern company today. When you set out to create a project team, it’s obvious with this structure you’re going to need specialists from a number of different domains to fulfill all the requirements of your project. Read more