Temporary workarounds shouldn’t last longer than permanent solutions

“The only difference between a caprice and a lifelong passion is that the caprice lasts a little longer.”
Oscar Wilde

How to get into technical debt

I think Wilde was on to something when it comes to the kludges, bodges and late night fixes that seem to rule our lives.
Rule our lives, you ask? How familiar is this story?  
“Our core system/application/ is bespoke/an older version of X. We modified it in the past to meet some specific needs. We’d like to move away from it or upgrade it, but we can’t.”  
Can’t patch because of that customization. Can’t migrate to another platform without a bunch of data cleaning. Can’t add new modules because they’re not compatible with the old base. 
You’ve got frustrated users, availability and confidentiality issues. All from a temporary workaround that wasn’t fixed when it was relatively easier. 
Welcome to technical debt and the interest is accruing. Where non-kludged systems can be patched and upgraded within regular service windows without the entire IT department on call, fixing this monster will require serious planning.  
Or you can continue living with it.  

Paying the past-due bill

Until it’s too late. The system goes down and only one or two people know how to make it work. Or it gets breached due to a nine year old vulnerability.   
How do you prevent this? One method I learned many years ago was to set a date when the temporary fix had to go away. I had to sign my name and put a date in the calendar. If I missed that date, I had to buy lunch for the IT department.  
That was incentive enough. 
Nowadays, you can select all kinds of ways to remind you of the things you should fix before you forget to fix them or how to fix them. We have no excuse to forget about it. 
And it prevents buying lunch for your co-workers or some stranger on the Internet. 

Relying on the kindness of strangers

If it's too difficult to bring up internally, let an outsider do it. Customers, auditors or consultants can be talked into nudging a reluctant organization into action

WannaCry as the Regulatory brown M&M 

If you were under a rock for the last few weeks, WannaCry is one of those cyber-security events that made it into regular news. If it hits NPR, that means everyone who knows me or at least strikes up a conversation at the bar will ask me my opinion.  
And my answers are the same as a hundred other security people who have already spoken up: Patch your boxes and do effective backups.   
Eat your Vegetables  
Backups and patch management is the cyber-security equivalent of "exercise regularly and eat a balanced diet" These don't make for sexy sales pitches for blinky boxes. The problem with cutting corners on boring fundamentals is that you aren't called on the debt immediately.  
WannaCry was a marker call for everyone who was gambling with patch management or backups. If you failed on one, you were in for some work but outsiders might not know. If you failed on both, you fell over visibly. You turned away customers or patients. You went dark while your operations team pulled all nighters. Eventually you brought it back, but you have to admit that you were a casualty. 
What's the long-term aftermath? 
I think we're going to see more ransomware. It's also going to be important for other reasons. Of interest to me, I think this will be the brown M&M that regulators and vendor assessment groups use to quickly determine the effectiveness of a company's security program.  

The Brown M&M

In the 1980's, the hard rock band Van Halen designed massive stage shows that required serious infrastructure at the concert venue. Their contract riders described the technical requirements required to support the lighting and stage. To ensure that someone actually read the document, the contract would require that a bowl of M&Ms was in the dressing room, with all the brown candies removed. If the candy dish contained brown M&Ms, there was a good chance that some pertinent detail was missing in the venue and it was time to inspect the setup.
This may seem unfair- after all, malware that encrypts volumes doesn't exfiltrate data. It's not a breach.
However, if I'm acting as an assessor or regulator, that event tells me you aren't doing the fundamentals here. Perhaps you're being sloppy elsewhere- maybe Test and Prod are the same environment. You may not be encrypting sensitive data on mobile devices. Core infrastructure could be fragile and creaky.  

So, I'll say it again. Patch your systems, do backups right so customers and regulators don't think you're a bigger risk than your competition.

On Changing Password Guidance: A Good First Step From Microsoft

On Changing Password Guidance: A Good First Step From Microsoft

Passwords, as a security solution, have become untenable. Whereas 15 years ago you might only have needed to remember two passwords, your ISP or your work password, now we have a plethora of passwords to keep track of. Power utility websites, water utility websites, bank websites, online payment websites, Facebook, Instagram, Twitter, Pinterest or any number of other sites that have our information. The guidance has often been to make passwords complex, alphanumeric, contain special characters, be as long as possible, oh and make them easy to remember but don’t reuse passwords and never write them down.

Reverse Engineering Firefox and Tor Targeted Payload

Reverse Engineering Firefox and Tor Targeted Payload

The Lotan research team is constantly seeking out new and novel memory corruption exploits to enhance our detection heuristics. This week, an exploit targeting Firefox and the Tor Browser was released, giving us a chance to exercise the capabilities of Lotan.