Cyberweekly #10 - That’s edition 8 in octal
Welcome to CyberWeekly, a weekly roundup of news, articles, long form blog posts and various other miscellania that interests your author, Michael Brunton-Spall.
Feel free to forward this on to people you think might be interested. If someone forwarded this to you, then you can subscribe to your own copy at Cyberweekly
Replies to this email come straight to me, so just hit reply to send me feedback, comments or links or tweet it to me @bruntonspall.
So this week we reach two milestones at more or less the same time. This is the 10th newsletter, that's 10 weeks in a row compiling and sending this out, as well as reaching 100 subscribers this week, so huge thanks to everyone who subscribes, who is passing it onto friends, and the several hints this week for things to add.
There are increasing numbers of companies and people talking about the sort of holistic security that I've been talking about for years. The Duo Security team inparticular (full disclosure, Rich Smith one of my coauthors is employed there) are on fire at the moment, constantly releasing great blog posts about how to do security in this new world, but I'm seeing more and more of it. So this weeks release is mostly happy good news :) I'm sure the cynical news stories will return next week.
Technical Intuition - Alix - Medium
"I didn’t want our organisational partners to learn to code, I wanted them to learn how to talk to developers. I didn’t want them to outsource complexity, I wanted them to learn what skills they need in-house, which they could contract out, and how that might change over time"
This article about technical intuition is party right, but misses the thing that I care about. It talks about how we are teaching people to code, but we aren't teaching them to talk to coders, we aren't teaching them to have an intuition about complexity, or what software can actually do today.
As Mike Bracken said recently "Hire 50 people under 30 who know what an API is.". Putting aside that I don't think age comes into this, we find that decision makers in organisations just don't have any people in their organisations who actually know what an API is, and what it can do. They might know the term, but they don't intuitively understand API's or how the internet and data is connected via API's.
To Trust or Zero Trust? | Duo Security
"The important thing about trust is that it’s neither binary nor permanent. You don’t trust someone to do anything at all; you trust them to do a particular set of actions, on a particular system, perhaps on behalf of a particular entity (such as a third party accessing a client record as a member of one brokerage firm). And you don’t trust them forever; you trust them for as long as certain risk-related conditions are true. You might stop trusting them in cases where enough time has passed that their password might have been compromised, or when their endpoint becomes vulnerable to a certain exploit by virtue of its software becoming outdated. This is the reason why network perimeter-based security is less than optimal: organizations tend to trust a user forever, to do anything, as long as they come from the right IP address and give the right password. We have known for a long time that open-ended trust is a bad idea, but given the available technology, it’s been a tough problem to address — until now."
This by Wendy Nather, is a great explanation of the problem of trust, including the explanation about different usages of the word trust, and why it's key to why the old model of bastion hosts and castle networks doesn't really work.
The worst truism in information security - The Blagoblag
"Attackers just need one vulnerability, defenders need to be perfect
This may be the single most repeated truism in information security. Just this week, a colleague invoked this, with the quip that those of us who've chosen defense must be pretty dumb, given the challenge of that task, and the possibility of an easier career in offense."
There is so much good in here, but I wanted to call out this attitude. If you think the job of being an ethical hacker/red team in your organisation is to win, to just break stuff, then you are part of the problem. The only reason you exist is to help the organisation, and just breaking stuff and walking away is not helping.
If your red team has this attitude, then you should get rid of them and get a new red team. A red teams job is about 10% breaking your stuff, and 90% sitting and working with the team to build a better defence.
Equally, as this article says, this dichotomy of systems being secure or insecure is entirely a fallacy. We know that we have unpatched systems, that there are possible vulnerabilities in our systems. We exist to help make priority decisions over how to spend a limited amount of security capital.
Security vendors and as a profession doesn't make enough of how to make reasonable choices on security, instead everyone is shouting that if you just fix passwords/install a threat detection tool/upgrade your firewalls/install an APT defence black box, then all of your security issues will go away.
You used to build a wall to keep them out, but now hackers are destroying you from the inside | WIRED UK
Organisations are also vulnerable at many more points. The internet of things is rapidly expanding what security experts call“the attack surface”. Intruders can now enter an organisation through a vending machine, a smart thermostat or a TV, not to mention one of the many connected devices that employees carry or wear every day. The gatekeepers, outwitted and overrun, have responded like authoritarian leaders attempting to clamp down on crime, introducing increasingly draconian security policies. But when employees subsequently find it harder to work, innovate and experiment, the business suffers."
As it says. I'd argue that it's not even the Internet of Things, it's people trying to work around the VPN, people using their iphones as hotspots, and people forwarding emails via their personal accounts that bypasses all of the "gatekeepers". But everything else here, I agree with.
For me, this is probably the long read of the week.
NIST Special Publication 800-63B
"Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."
I was asked something this week which reminded me of this NIST standard. If you are working with someone who insists that your passwords have complexity rules, maximum lengths or regular rotation, note that this is now strongly discouraged by a US Government standard. Anybody insisting on this is insisting that you are not compliant with best practice and standards. The lists of what they do request is also interesting (and has been covered many times before), but its worth noting that testing against breached password databases, like HaveIBeenPwned is strongly recommended.
Google - Site Reliability Engineering
"The Site Reliability Workbook is the hands-on companion to the bestselling Site Reliability Engineering book and uses concrete examples to show how to put SRE principles and practices to work. This book contains practical examples from Google’s experiences and case studies from Google’s Cloud Platform customers. Evernote, The Home Depot, The New York Times, and other companies outline hard-won experiences of what worked for them and what didn’t."
This is a valuable addition to the SRE book, which I think is a great model for security teams as well as for operations engineering for any organisation moving from a small (<150 people) to medium/large (>300 people).
Thread by @nevali
"GDPR recognises that data collection in exchange for “better” advertising is essentially a transaction, but one which was being conducted without any freely-given informed consent"
This thread from Mo is a great description of the intent of GDPR, but also how it has been interpreted and implemented by news organisations in particular. Showing users a list of hundreds of possible companies that might set cookies is definitely a breach of the intent of the law, and we'll see how the public and the ICO actually responds over time.
Google: Security Keys Neutralized Employee Phishing — Krebs on Security
“Users might be asked to authenticate using their security key for many different apps/reasons. It all depends on the sensitivity of the app and the risk of the user at that point in time.”
This, if true, is an amazing protection against the most common attack mechanism for organisations. Before you go implement it at your org, note that they worked on the usability. You don’t get asked every time, you get asked for the key if there’s some reason for it. That matters in making this a success.
I think this for me is one of the more valuable things that you should be getting your high vulnerability staff to be using for all of their accounts. Buy a set of U2F FIDO keys and deploy them across your system administrators, finance heads, or whoever else you think is high risk. Provide them for your staffs personal use as well, and get ones that work with NFC for their phones if you can.
Singapore Hack Is a Speed Bump for $9 Trillion Industry - Bloomberg
"Lee himself signed up for the country’s digitization project, saying that doing so would improve the quality of care across medical professions, though he posted on Facebook that he was aware of the downsides.
Of course, I also knew that the database would be attacked, and there was a risk that one day despite our best efforts it might be compromised. Unfortunately that has now happened.
His calm response, rather than outrage, is appropriate among those trying to build the future of health care, though it’s scant consolation to people whose records were accessed. "
This is a great overview of how a calm sensible response can result in fairly positive news coverage, and how a suitably briefed leader can make everything seem calmer and better.
That's all for this week. See you next week.
Michael