Agile? Or FrAgile?

Leave a comment March 7, 2023 Thom Langford

(I found this piece deep in the vaults at (TL)2 Towers, so I figured I would break my non-blogging streak.)

“Sensitive client code has been discovered on a GitHub repository, and it looks like one of our developers put it there. The client is upset, and their Chief Information Security Officer (CISO) wants to meet with you in New York to discuss what happened.”

Not the best email start to a Tuesday morning, I grant you, but I did at least have two things in my favour; six days before the meeting with the client and an excellent Cyber Incident Response Team (CIRT) headed up by a very talented and focussed individual based out of Miami. So I felt confident we could get to the bottom of the incident.

Fast forward to the following Monday afternoon (don’t worry, this isn’t a blog about cyber forensic investigations), and I am walking out to the cab back to the airport with a thankful, happy client and the promise of more billable work in the form of security testing.

It sounds like the beginning and end of two different stories, but this is a real example from back in 2016 during my tenure as a CISO. What initially felt like a nightmare scenario was quickly turned around, and three things became apparent very quickly:

Proper incident management is crucial because it is not a case of “if we have a data breach” nowadays but “when we have a data breach”.
Agile working methods are a double-edged sword; we get work done quickly and effectively, but if we are not careful, boy, can it bite us in the ass.
Focusing on the client, their perceptions, need for honesty, demands, and wishes are paramount.

I want to focus on 2 and 3 from above because let’s face it, incident management is often carried out by the cool-looking security folks who swoop in when it all goes wrong.

Is it Agile or FrAgile?

Agile working methodologies are, I am told, wonderful ways to get work done quickly and effectively. Flexible working, the heavy reliance on technologies, still often in early release stages and updated daily. You can reuse and share code through various repositories, test things out with the rallying cry of “Fail fast! Fail often!”, pull out your credit card and spin up servers on the other side of the world by the time the kettle has boiled or the coffee machine dripped its last drop.

The problem with this is that if we are not careful, the environment becomes the wild west, with code flying around various platforms containing hardcoded admin credentials and schematics shared openly as you struggle to squash that last bug with the help of the internet. (I am having palpitations just thinking about it.)

Sticking code up onto GitHub doesn’t make you agile; it makes you fragile. You must prepare and plan, work as a cohesive unit with your team and have established (and secure) ways of working with these new and funky tools that are not only effective but also in the best interests of the client.

The client is King AND Queen.

I recall another incident where a client contacted us to say they had found their code and credentials on a GitHub-type site. They were (unsurprisingly) very upset and demanded our response. Upon investigation, it turned out the data in question was uploaded there some two years earlier, was out of date, and the credentials were changed long ago anyway. It was severe, but we were off the hook with confirmation that third parties downloaded none of the data!

Famous last words. The client was livid.

The incident escalated to their board, and we were bought to task for the security lapse in no uncertain terms. However, we had forgotten one crucial thing in all of this; it wasn’t our data to lose in the first place.

There is a saying in information security circles; “my risk model is not your risk model”. It means that what risks affect you are not the same as those that affect me. Precisely the mistake we made with this client. It didn’t matter that nothing had happened; it didn’t matter that the data and credentials were stale; we were sloppy and slapdash with their intellectual property. We had broken their trust.

In the middle of the high-pressure project environment, losing sight of what the client holds dear versus what you are trying to achieve in the here and now is easy.

Making the Leap

Do you need to address your agile working practises and understanding of your client’s motivations and risks? Here are two data points to consider:

A constant increase in the inclusion of unlimited liability clauses in your contracts. Right or wrong, they aren’t going away, and as you access more of a client’s sensitive and confidential data to “make digital work” for them, it will continue to do so.
When it happens, the cost of a data breach is increasing. According to the Ponemon Institute/IBM Security report “2019 Cost of a Data Breach Report – A comprehensive analysis of data breaches reported in 2018,” the average cost of data breaches has increased by 12%, a whopping $3.92M in the healthcare industry alone. You won’t get much change out of that for a satisfactory bonus pool.

When you leave your house in the morning, you lock your door, maybe enable an alarm system. When you leave your car, park it in a reputable garage and lock the door, immobilising the engine and setting the alarm.

Then you go to work and copy someone else’s confidential data and credentials to an open file share. Can you see the paradox?

Taking that leap in maintaining client confidence, assuring them of intelligent decision-making, agile (not fragile) working practises and mental rigour to maintaining their crown jewels is challenging. But it is essential.

Why did that first client give me more business after a breach? Demonstrating that we were in control of our processes and ensuring he and his risks were obviously the centre of our world helped: that and a high degree of transparency. But that initial breach was too high a price for extra business and a warm handshake.

Why do we put brakes on cars? Perhaps not for the reason you think.

Leave a comment February 23, 2015 Thom Langford

I have never liked the analogy;

Why do we put brakes on cars? So we can go faster. Therefore we put security controls in place so we can do riskier things.

I mean, I get it, the analogy makes sense, but like many analogies, if we are not careful they are likely to become a little too one dimensional. We also have brakes on cars to slow down for traffic lights, to ensure we don’t go too fast and run into the back of the car in front, and also to stop the car quickly to avoid someone crashing into us. I am sure with a squeeze and a shove we could fit these analogies into an infosec analogy, but why bother?

I was reminded of this particular analogy and why I don’t like it this morning as I read my paper. The headline really resonated with me;

‘Living rooms’ on wheels put drivers at risk

The Times, Monday 23rd February 2015

The article discusses how the increase in technology in cars has actually led to an increase accidents in recent years. The anti-lock brakes, stability control etc. is creating complacency amongst users, and putting them and others at risk.

If we are not careful we are shifting towards this in our industry. It is of course a good thing to focus on secure coding practises, OWASP, secure by design etc., because that is as important as a seat belt and an air bag in a car (oops, see how easy it is?!), but if we try and put everything into those particular controls, we are abdicating responsibility away from the user more and more. By creating an insulated and isolated environment in which they operate there is no positive/negative feedback loop, no opportunity to learn from mistakes, near misses or even dumb good luck. They quite literally are on their own being guided only by what their immediate vicinity is reporting to them. Another quote;

They are as uninvolved in the process as they can possibly be

This could be describing our users and clients who we are removing more and more responsibility from when it comes to making sensible, thought out decisions about basic security. We are removing their perceived responsibilities as they say to themselves “if the system is letting me do this, it must be alright” as they download malware specifically designed to undermine so called built in security. (Actually the quote is from Peter Rodger, chief examiner for the institute of Advanced Motorists commenting on cars being turned into living rooms.)

Let us continue to understand how mature our security development framework is, let’s observe the OWASP top ten, but let’s also continue to establish clear guidelines, education and expectations of our people at the same time. If we don’t, we may be congratulating ourselves little too early for running a good security programme.

If we do that, we risk going back over a century in time, and putting the cart before the horse, let alone putting better brakes on the car.

(If you want good analogies however, that can help your people truly understand the information security environment they are operating in, head over to the The Analogies Project.)

Securi-Tay IV

I will be spending the end of week with the Abertay University Ethical Hackers at their Annual Securi-Tay conference in Dundee. It’s a great conference so if you are at a loose end for Friday and in the area make sure you rock up and say hello to the lovely folks up there!

Three Envelopes, One CISO

2 Comments December 1, 2014 Thom Langford

The outgoing CISO of a company meets his replacements for lunch the day before he starts. He hands the newcomer three envelopes, labelled 1, 2, & 3.

I have one piece of advice for you. Whenever you have a breach, open each envelope in turn.

The job continues as expected over the months, when the fateful day come and the company suffers a security breach. Just before he is called into the boardroom to represent himself, he remember the envelopes and opens the first one. Inside, the card reads:

Blame your predecessor.

This he does and moves on.

A few months later another security breach occurs. Standing outside the boardroom, he opens the second envelope”

Blame your team.

A few months later, a third breach occurs. With a smile on his a face and spring in his step he approaches the boardroom confident he is going to get away with it again. As he is called in, he opens the envelope, mentally preparing to talk his way out of trouble. His eyes widen as he reads the card:

Prepare three envelopes.

Last week saw the rather shocking news of the Sony security breach that suffered a very overt attack on Sony and multiple days of downtime. Rumours abound around if it was an insider job, the extent of the damage, the rebuilding of the entire Sony Active Directory structure and wiping of all workstations and reinstallation of operating systems. The exact details will no doubt take many months to surface, but one thing seems to be clear; the blame of the breach is being squarely laid at the CISO’s (and sometimes the CIO’s) feet.

One article from IT Security Guru supported this with a quote from Phil Lieberman, CEO of Lieberman Software:

This was a perfect example of sloppy IT security and a CISO that did not implement proper privileged identity management, or a disaster recovery backup plan for continuity of business. The consequences were a loss of control over his environment caused by a focus on convenience of IT rather than the security of the enterprise.

This may well be true of course, and the Sony CISO may well have been incompetent in this instance. There is however a very real alternative possibility. What if the CISO had been very clear in the dangers in this case of convenience over security? And what if the board, or other senior leadership simply felt it was too “expensive” culturally and from the perspective of impact to the current productivity of the company. Sony is a strongly creative focussed business; it is not a bank, an energy company or in a regulated environment, so they are not forced to carry out particular security activities. The ability of their employees to not work as flexibly and without restriction could well be seen as a higher risk than that of a breach (even after the 2011 breaches).

Perhaps the cost of this breach will simply be a blip in the years to come.

The key thing though is that the business may well have accepted this risk and simply moved on, much as they would have accepted a financial risk and moved on. Sometimes financial risks results in massive downturns in business, and I don’t always see the CFO being pilloried on the first day without evidence – that is normally reserved for the CEO or Chair of the Board.

We seem to want to chop down the CISO as soon as something goes wrong, rather than seeing it in the context of the business overall.

Let’s wait and see what actually happened before declaring his Career Is So Over, and also appreciate that security breaches are not always the result of poor information security, but often simply a risk taken by the business that didn’t pay off.

I’m off now to get my PS4 in a fire sale.

A more secure cashpoint/ATM transaction?

Leave a comment March 24, 2014 Thom Langford

There has been much written and talked about over the years about the use of skimming devices and cameras being installed on cashpoints (ATM’s for my international readers), their increasing complexity and ability to seamlessly blend into the cashpoint itself. With the card being entered and read, and the PIN code either intercepted with lay on keypads or filmed with cameras, the criminals ability to clone cards is quite significant, and the financial rewards high. Most of us, if we were honest, would struggle to see a sillfully crafted and installed skimmer on an average ATM.

Why are we still so reliant on this kind of security? Sure, it is technically two-factor, with the card that I have and the PIN that I know, but as my previous statements show very clearly, this security can be bypassed very easily.

The Royal Bank of Scotland (RBS) quietly announced a new feature last year to their mobile app that allows cash to be removed from an RBS or NatWest cashpoint without a card. Given there has been much research on the fact that people were no more likely to forget their wallets and purses than their phones, and actually become more distressed at not having their phone over their wallet, the bank could see a shift in how people were becoming increasingly reliant on their smartphones.

The process is straightforward; after logging into the (already downloaded) app, and pressing “Get Cash” one simply types in the amount of money they would like to withdraw, and is then presented with a six digit, one time use PIN. This PIN can also be texted or sent to someone else if need be. (VERY useful to help out friends and family in distress.) One then uses an RBS or NatWest cashpoint (unfortunately other banks do not participate in this scheme) , presses enter on the keypad, and then enters the six digit PIN number twice followed by the amount of money that was originally requested. The cash is then dispensed. If more money is required, the process is repeated and another, different, six digit PIN is issued.

To my mind this is an excellent innovation, and other thought so too, with the creators behind the enhancement, SapientNitro being awarded a Cannes Lion at last years show. A slightly cheesy advert follows…

(Note: at this point it is worth me declaring my interest, as I am an employee of Sapient, the parent company of SapientNitro. That said, I was using the service before I realised it was Sapient that came up with the idea in the first place!)

This works in many ways:

1: The pin is only used once, so it doesn’t matter if a skimmer is in place, it is recording only a one time password.
2: Your card cannot be cloned as it is never used.
3: It is convenient because nights out only involve looking after your phone, not you phone and cash card and cash!
4: Even if you phone is lost, it is password protected, tracked, and you r banking app is also PIN protected with more than a four digit pin code (it is, right?). You can also wipe your smartphone remotely in most cases.

A UK food chain, Pizza Express, did a similar thing last year as well, whereby on the bottom of the receipt is a unique code that allows people to pay with PayPal; again this is smart (your misgivings about PayPal aside) as your card cannot be taken around the back and cloned without your knowledge, as the payment is sent directly from PayPal to the restaurant and notification received on the till. Of course every time I have tried to use it the code has always been misprinted stopping me from doing so! Lovely idea nonetheless…

So what is the upshot of this? Most importantly I think it shows how with the judicial use of technology we can keep one step ahead of the criminals. Of course they will catch up, and of course there are other security implications (a rise in smartphone theft perhaps?) but RBS has shown that a relatively small change in their systems can result in a huge change in the security of their transactions. As of writing I am not aware of any other UK bank having this capability (they seem to be focussing on the ability to send payments to friends rather like PayPal than anything else), but this kind of approach should become the new norm.

It is this application of security alongside the ability to truly understand their clients and their needs that in this case has allowed RBS to steal a march on their competitors. I know this simply because of the looks on the faces of my friends when I take cash out of the cashpoint without using my card; it is magic, and they like it…

This is truly a case over security versus convenience… but with added convenience.