Luck and Skill

Career advice: Deciding what job to aim for next

Fri, 26 Dec 2025 15:48:00 +1100

One of the things I love most about my work is that people ask me to help them think through challenges and opportunities. And I’ve gotten to a point in my working life where people often ask for career advice. I don’t necessarily feel like my career is itself under control, so I always caveat the advice, but I’m really happy to share what I’ve learned along the way¹.

In these conversations, one of the most common questions is “How do I work out what job to go for next?”. I really respect the complexity of the question, since:

there are so many kinds of possible jobs,
they become available pretty much unpredictably (although subject to economic cycles, etc),
the path to developing the skills and experience for them can be wildly different, and
you don’t have infinite time to build the skills to be credible at everything.

It’s also really hard to work out if you’ll like a job before you start it - and everyone has heard a horror story about a new job not being what they expected.

In these conversations, I usually recommend that people with those questions try three exercises: get more clarity about what you (really) want, then reduce the possibilities, then talk to people.

Working out what you want — Three column exercise

Try this exercise. It’s my version of what is essentially a skills audit - with explicit focus on how you feel about those skills.

If you can, try to get a bit of quiet time for this, at least initially - maybe head to a coffee shop or a library; somewhere out of your usual spaces. It could also be something that you could do on a commute.

Grab a blank sheet of paper, turn it to landscape, and then divide the page into three columns².
In the middle column, put “Skills and Experiences that I have, which I want to use ✅”. In this column, you’re going to collect all the things that you’re good at, which you want to keep using. These are the skills that help you work out which roles you can contribute strongly to on day one, and that are going to provide great stories to tell in the interview.
On the left column, put “Skills I’m leaving behind 🚩”. We’ve all got skills that we’re kind of done with, that we don’t want to do any more³, and that’s okay. Being clear about what those skills are is helpful, as it can then help you assess (and filter) potential roles against how many of these skills they’re going to ask you to use.
On the right column, put “Skills and experiences I want to acquire 📈”. The neat inverse of those red flags is growth — most of us get a sense of accomplishment, even joy, from acquiring new skills and demonstrating mastery. Changing roles can be a particularly intense source of new skill development opportunities, so knowing what kinds of opportunities you’re interested in can really help you find the best opportunity.
Start brainstorming into each of those columns. The critical thing here is being honest - this isn’t for anyone else to see, so your only audience is yourself. Don’t write what society, or your colleagues, or your boss, or your parents told you should write. Don’t write what you think the “right” answer is. Write what your heart and mind tell you is true for you. In all the years I’ve been encouraging others to do this exercise, nobody has ever shown me their answers to these questions — and that’s totally okay.
Carry it around for a few days (or a photo of it, if you don’t want to carry the paper itself), and add things as they occur to you. Very often, you’ll get the first 80% out in a burst of activity, and then your subconscious will keep thinking about it - make sure you can capture those thoughts as they appear.
Once you’re done, you’ll have something that can help you navigate toward what you want, and away from the things that are going to drain you.

Reducing the search space — Crossing off what you don’t want

Many years ago, I read The Now Habit by Neil Fiore, a book about understanding what drives the difficulty some people feel about starting tasks and recommending some tactics for reducing that difficulty. One of the core tactics is The “Unschedule” - essentially, putting all the non-work things that you need to do (including rest!) into your calendar, as a way of visualising how much time you don’t have available, to help you create the feeling of time pressure sooner and therefore get started earlier.

You can take a similar approach to working out what jobs you might be interested in. It’s okay if you don’t even know what roles exist — this exercise will help you to get a sense of the landscape.

Grab the biggest list of relevant jobs that you can find – if you work for a big company and they have a standardised list of job titles/roles, that’s a great option; else, look at an industry framework like SFIA for IT, SFIA for Cyber. If you’re not in tech, look for your industry’s equivalent.
Cross off every job you definitely don’t want. Be ruthless. Again, this is for you and nobody else ever needs to know. You’re not making value judgements about the people who are in those roles, you’re just trying to work out what’s right for you.
Of the jobs you haven’t crossed off, circle the groups that are most interesting to you - with a particular focus on those you know least about. What are the questions you would ask the people who are experienced experts in those jobs? Would you want to know what the work involves day-to-day? Or which skills are most important? Or how they developed their personal credibility for the role?

Reducing the uncertainty - Talk to people

Once you’ve got a list of interesting roles and questions you want to ask, there’s one more step: go find friendly people in those roles, ask those questions and make friends.

Finding people can be a bit varied. Again, if you have the benefit of working somewhere large, you can often just look them up in your internal directory and reach out.

Many people are really quite happy to talk about their roles – particularly what they find most interesting about it, how they got into it, what they’ve learned. So, you should assume that it’s probably safe to gently ask, maybe something like “I’m really interested in moving into a role in your field, but I don’t know a lot about it - what do you find most interesting about your work?”, and go from there. If you show them genuine curiosity and ask the follow-on questions, it’s not unusual for the conversation to run for a while. And if they don’t want to talk about it, that’s fine - just gently move on to the next person when you can, and try again.

Otherwise, industry associations and interest groups can be great sources for this kind of thing - anything that runs meetings or gatherings of people. Helpfully, the kind of people that will go to a gathering tend to be extroverts (or outgoing introverts⁴) that are going to those meetings to talk, so you don’t have to wonder about whether they want to talk.

(If you (like me) are in that introvert group, then I know cold outreach can feel impossible - often grounded in concern that you might be bothering the other person. Often though, people are not bothered by a question about their work from someone genuinely interested, and they can be delighted to chat. So, please experiment with asking.)

Final thought

A few years ago, I was on an internal leadership development course at my organisation where we heard from most of the EVPs about their career journeys. I was really struck that none of them said they had a specific plan for their careers, given how ubiquitous that career advice is; instead, they consistently said that they had navigated by their principles (of various kinds), and that they had reached very senior executive roles. One said “I know how I want to contribute and I know what I’m good at, and I look for my next role to match that” (approximately).

That was helpful for me in two ways. It gave me permission to not have a plan, and to put down the guilt I had felt about not having a clear idea of what I wanted. And more importantly, it prompted me to focus on creating clarity around how I want to contribute, what my principles are, and to sharpen what I’m good at. That’s served me well since.

(Of course, these are the people who made it, so take it with appropriate salt. This isn’t proof that you will be successful if you don’t have a plan; just proof that you don’t necessarily have to have a plan to be successful.)

So, if you’re at a bit of a career crossroads, you’re not alone. It’s a normal part of working life. Hopefully, those tactics will be useful to you in collecting some information and in focusing your search for what you might choose to do next. Best of luck!

And one of the things I’ve learned along the way is that (approximately) nobody feels like their career is fully under control. ↩
You can do this on a computer if you want to, but it seems to work much better on paper, particularly in the initial drafting phase. ↩
I often tell the story from early in my career where I was asked to create an updated system diagram - the company had a printout of the old one, but nobody could find the Visio file - so I sat in a meeting room for a couple of hours while a dozen people each explained their bit of the system and how it all connected; I tended to be more cautious about admitting I could use Visio after that. ↩
For those that don’t know me personally, some context: I’m an introvert, I have anxiety, and I find events with lots of people daunting. And: I really enjoy connecting with people individually, and my job often requires me to go to those kinds of events - where I often find that I get chances to have really interesting conversations. So, I am in that “outgoing introvert” - I can find great joy in those conversations, and I ~always need recovery time afterward. ↩

Getting better at saying "no"

Sat, 08 Mar 2025 16:15:00 +1100

I really like to help people - it feels good, and it generates value. Fortunately, work is full of lots of opportunities to help people. Unfortunately, I also tend to be wildly optimistic about how much capacity I actually have - underestimating how long it will take to help with something, and underestimating my existing commitments. The intersection of those various things means that I sometimes get wildly overcommitted - and have to work silly hours to dig my way back out of those commitments. That works okay, I guess… but I’m not in my 20s any more (or my 30s), and I’d prefer to reduce how often this happens.

Improving things has meant:

Moving to a single view of all of my existing commitments, so that I can see at a glance how much is already on my plate.
Sharpening my decision algorithm from “Could I help with this?” to “Am I the best person to help with this?” (and “best person” doesn’t mean “most experienced” – routing work to people who want to grow in that area is a gift to them).
Changing my capacity attribute from “Will I have time?” to “Will I have both time and energy?”.

All of those are habit changes, so it’s a bit of an iterative change process - but those habits are starting to shift. As a result, that decision process is increasingly telling me I should say “no” to more requests.

At the same time, I have a lot of anxiety about disappointing people or saying the wrong thing. Saying “no” feels like it is going to be disappointing. And coming up with the right thing to say can be a bit agonising - it’s not unusual for me to spend five minutes rewriting a “Sorry, this isn’t something I can help with right now” email. All that means that I sometimes end up saying “yes” when I don’t want to, because saying “no” burns up too much energy.

A colleague brought this up at a dinner the other night and had come up with a great tactic: “We just have a list of standard ways to say “no” to meeting requests - and we pick one at random each time!” Simple, brilliant. Even if you don’t use the templated phrase exactly, you’re not starting with a blank page, so it’s much easier to get it done. I wanted that list too.

In parallel, I’ve been experimenting with using LLM chatbots for more things at home to get a sense of where they can be helpful. Anthropic’s Claude Sonnet 3.7 is currently my default for anything complex that requires an online model. Asking Claude:

Come up with a phrase book for how to gently say “no” in various contexts at work. (Context: I’m a professional manager with [n] direct reports and about [n] people overall, and I’m in [country].) Include at least 40 phrases overall, all professional, and include a mix of “no”, “not now”, delegation and other scenarios.

emitted a surprisingly useful list of 50 phrases in about five categories. That inspired some other categories, so a few more requests caused Claude to add some other categories and phrases. I printed a copy and put it next to my desk.

A few days later, I was running an errand and got a question which was best delegated – but I didn’t have the list handy. I copied the list into Notes.app, but then thought that it’d be cute if it was a basic web app too. Fortunately, Claude is now really good at this too. I asked it:

Create a simple, plain Javascript web page based on the attached Markdown file, which prompts the user to select a list, and then shows a randomly-selected item from the list.

Items are grouped into lists under second-level headings (starting with “## “). Each list should be shown as a big button, with the name of the list appearing as the title on the button.

Lists are grouped into topics under first-level headings (starting with “# “). Each group should be shown as a box around the list buttons for that group, with the name of the group appearing in the top left of the box. Each group should have a different color, and the list buttons in that group are that color.

When the user presses a button, the app randomly selects one quote from that list, covers the page with a large, semi-transparent box, and prints the quote in large text in that box. The quote text should be large enough to easily read, but still all fit on one screen. Within that box, underneath the quote, two buttons appear: “Retry” and “Close”. If the user clicks “Retry”, the app selects a different quote from the same list, and updates the large quote text to that value. If the user clicks “Close”, the app removes the large quote box and returns to its original state.

The app should be entirely contained in no more than three files: an HTML file, a CSS file, and a JavaScript file.

The result was impressively functional - about 95% right in one shot. A few adjustments to the phrasing of the quotes, reorganising the categories to make them a little more consistent, and the layout of the CSS, and it was good enough to call v0.1. I was really impressed at what Claude can churn out quickly – building this myself would realistically have taken a couple of hours, rather than the ~15 minutes it took using the LLM.

You can play with the resulting app at no.luckandskill.io, and the code is available on GitHub. I hope it helps lower the friction on saying “no”, so you can make more progress on the things that really need your attention.

→ NYT Opinion: America Isn’t Ready for What’s Coming

Sun, 06 Mar 2022 10:15:35 +1100

Glenn S. Gerstell writing in NYT Opinion:

Last week President Biden warned Mr. Putin against Russian cyberattacks on the United States’ critical infrastructure. But American businesses aren’t ready for a war in cyberspace. Although Mr. Biden designated the Department of Homeland Security to lead what he vowed would be a forceful response to any such aggression, this isn’t enough. The D.H.S. doesn’t have the legal authority to order the private sector to follow its lead. More broadly, the federal government, even if warned by companies like Microsoft of incoming cyberattacks, doesn’t have the necessary infrastructure in place to protect American businesses from many of these attacks.

That the United States has to resort to threats of retaliation is itself a problem. America should already be cyberattack-proof, but coordinating these efforts across the country has been an uphill battle.

There’s much in this article that’s good – particularly the proposal to rationalise per-sector cyber regulation with a single, cross-sector cyber regulator. Simplifying the regulatory landscape would help US firms cut the complexity of understanding and complying with cyber obligations.

That said, I’m somewhat bewildered at the absence of any mention of software quality from the piece. Nothing about enforceable minimum standards and requirements (e.g., 2FA on email services), or fines for critical vulnerabilities, or even removing software liability waivers. Software remains the only industry where you can sell a $1 bn of something to someone, and assert zero guarantee that it works or is fault-free, and everyone seems to be fine with that. It seems surreal that the problem could be so critical that the regulators should be unified and the private sector should have their cyber defences regulated, but that we would still do nothing to regulate the root cause issue: software vulnerability (code or configuration).

The weekly reports of ransomware attacks and data breaches make it clear that we’re losing this battle.

This is a common assertion, but there’s not much evidence for the claim. Since the early-2000s, there has been a constant battle with cybercrime, but the criminals are not winning. Instead, there’s equilibrium point that moves as attackers and defenders each improve. The widespread adoption of cyber insurance moved that equilibrium point, making it more practical for criminals to attack companies (rather than just consumers). Attacks on companies for multi-million dollar ransoms are far more newsworthy than small-scale fraud, so public awareness has been easier to raise; that creates the impression that it’s bigger than before.

(Thanks to James for the prompt.)

Sprinting a marathon: scaling vulnerability management

Sun, 06 Feb 2022 15:49:16 +1100

If your patching teams are reporting that they’re exhausted, they’ve got good reason. If you haven’t already, it’s time to invest in automation – regression testing and continuous deployment – to help them cope.

NIST publishes the National Vulnerability Database, which provides a pretty good index of all known vulnerabilities. It counts vulnerabilities, each identified by a Common Vulnerabilities Enumeration (CVE) number.

Over the last six months, NVD has recorded about 2,000 new vulnerabilities per month, including about 250 critical¹ vulnerabilities per month (remote code execution, which might mean emergency patching). That’s about 12 new critical vulnerabilities per week day and about 90 less-serious vulnerabilities. That’s a pretty high workload for a triage team, much less the patching teams.

Month	Critical CVEs	Total CVEs
2021-08	252	2236
2021-09	219	1917
2021-10	202	1708
2021-11	219	1610
2021-12	343	2400

That’s already not great, but the problem is intensifying. Here’s a graph² of critical and total vulnerabilities published per year.

Source: NIST NVD Data; our analysis

The trend line on critical vulnerabilities suggests this is going to get worse. Treat it as approximate³, but it suggests that you should expect the number of critical vulnerabilities per year to increase by about ~250 per year. In 2022, we should expect nearly 3,000 critical vulnerabilities to be released.

So, how do you deal with this kind of volume?

Problem one: discovering that you’ve got something that needs patching

There are three useful capabilities here, in decreasing utility (and usefully decreasing cost):

A comprehensive inventory;
Vulnerability management (scanning) systems; and
Monitoring for advisories.

The ideal primary control is a comprehensive inventory of your estate. You could then check a daily extract of the NVD against that inventory, and create work tickets for every team that owns a newly-vulnerable component. In an ideal world, your CMDB is even automating this for you. That said, there’s pretty good chance that practitioners will have either scoffed or grumbled when I said “comprehensive inventory”; I’m not aware of an organisation that thinks it has solved this.

Given that nobody fully trusts their inventory, many organisations augment it with scanning. Typically, this is implemented with a vulnerability management system. Network-based VMS are common, but these can struggle with reachability and completeness (particularly if scans aren’t authenticated). With the increasing frequency and severity of library-level issues, it’s also worth augmenting your network VMS with something that’s keeping an eye on vulnerable libraries; one open source option is Anchore’s grype, which can scan container images and file systems.

The third layer of detection is inexpensive but narrow: relying on your vendors telling you, whether that’s through predictable schedules (e.g., Microsoft Patch Tuesday) or mailing lists. That’s probably best thought of as only being for your most critical and/or widely deployed software, given that it’s unstructured data and difficult to scale.

That said, those answers aren’t particularly satisfying. Hopefully, the state of the art in both automated inventories and vulnerability management will continue to improve completeness and granularity.

Problem two: patching it

Once you know you’ve got something to patch, the hard work begins.

Patching teams typically struggle with the volume of required patching because patching processes are traditionally manual and involve a lot of analysis. A typical process might look like:

Triage team says a patch is available.
Analyse patch and perform criticality analysis. (“Do we need to patch this? How quickly?”)
Deploy patch to development/test environment.
Perform manual regression testing in dev/test environment.
Review regression test results; plan for production release.
Deploy patch to production environments.
Perform manual regression testing in production environment.
Monitor for performance impacts.

We can make life easier for ourselves if we make two changes – one cultural, one technical.

The cultural change sounds simple: don’t decide per patch, just patch everything, continuously. If we deploy every available patch, every month, we might have more patching failures but that is offset by freeing up significant time by no longer performing analysis. As a bonus, it also becomes much easier to stay in a supported state.

The technical change requires some capex: automate regression testing and deployment. If you reduce the friction of patch deployment (and roll-backs when necessary), your ability to patch everything continuously dramatically improves.

Those two go together: if you don’t have great regression testing, automatically patching can increase your software supply chain risks.

But where you can implement these two changes, the reward is a much simpler process:

Detect that patch is available (triage controls above).
Automated deployment of new version to development/test environment.
Automated regression test passes (or blocks the pipeline and generates an alarm).
Automated deployment of new version to production environments.
Monitor for performance impacts.

You’re down to two manual processes – kicking off the process, and handling any exceptions.

Migrating legacy applications to pipelines can be an expensive one-off change, but given the increasing number of vulnerabilities every year, it’s worth considering.

My thanks to Cole for providing feedback which helped improve this post.

In those numbers, we have counted vulnerability as “critical” if it has a CVSSv3 severity of CRITICAL; or a CVSSv2 base score of 10 if the record has no CVSSv3 score. Typically, those are remote code execution vulnerabilities – the patches you need to get implemented right now, to stop a system compromise. ↩
The code to generate the graphs is here, if you’d like to tinker with it. ↩
The linear regression has an R² value of only about 0.81. ↩

→ White House Meeting on Software Security

Sat, 15 Jan 2022 18:54:23 +1100

Following on from the log4j vulnerabilities of late last year, the White House held a meeting on software security with government, private sector and open source representatives. (I was wrong: they invited the Apache Software Foundation).

The readout provided by the White House sounds like the conversation was directionally positive, and developed a useful framework for how to proceed:

The discussion focused on three topics: Preventing security defects and vulnerabilities in code and open source packages, improving the process for finding defects and fixing them, and shortening the response time for distributing and implementing fixes.

In the first category, participants discussed ideas to make it easier for developers to write secure code by integrating security features into development tools and securing the infrastructure used to build, warehouse and distribute code, like using techniques such as code signing and stronger digital identities.

In the second category, participants discussed how to prioritize the most important open source projects and put in place sustainable mechanisms to maintain them.

In the final category, participants discussed ways to accelerate and improve the use of Software Bills of Material, as required in the President’s Executive Order, to make it easier to know what is in the software we purchase and use.

The participants from ApacheSF published their Position Paper in the lead in to the conversation, which is interesting reading. The paper is cogent and worth reading.

That said, it seems determined to perpetuate a “buyer beware” approach to software, which is isn’t great. It’s entirely understandable that an open source organisation like ASF can’t exactly offer a warranty for their software, but that same belief bleeds into commercial software and is one of the root causes of our global cyber problems.

The other theme that comes through the paper is a frustration with how few users of open source software then also become contributors to open source (particularly large companies which rely on those components to generate revenue). This is a theme that seems to be burning quietly underground in a few parts of the community, occasionally appearing as spot fires, like the deliberate corruption of two npm libraries as a protest over a lack of funding. Here’s hoping that we’re on an inflection point around making open source more sustainable, this isn’t a sign that the great open source experiment isn’t on the precipice of a slow collapse.

Centralised decentralisation: blockchain's promises are hard to keep

Sat, 15 Jan 2022 18:46:00 +1100

There has been a few great articles on the web3 movement and blockchain proponents recently, which draw out a couple of themes.

Molly White’s Blockchain-based systems are not what they say they are sets out a useful structure:

If you go out seeking to learn from their proponents why blockchains and the systems built atop them are apparently the future of our web, you’ll begin to see some common themes. Two of the ones I see most frequently are:

Decentralization: data in blockchains are distributed across innumerable servers run by innumerable people and organizations, rather than stored on servers controlled by one organization

Immutability: what is written to a blockchain cannot be changed or deleted, unlike more traditional databases These fall apart under further scrutiny.

The analysis that follows is cogent and clear, and leads to a conclusion that:

Blockchain technologies have somehow managed to land in the worst of both worlds—decentralized but not really, immutable but not really.

This aligns with Moxie Marlinspike’s “first impressions of web3”. He sets out a quick summary of web1 and web2, including two forces that shaped them:

People don’t want to run their own servers, and never will.

A protocol moves much more slowly than a platform.

He then explores how those forces are shaping web3’s reality. In a practical sense, the former means that most people access web3 through a small number of value-adding services — as a result, the lived experience isn’t the decentralised blockchain but the centralised service. Once that starts to happen, he argues, those central services become platforms which out-innovate the underlying decentralised protocol, meaning that the value consumers receive increasingly comes from the centralised services (and we’re back to a web2 world).

The other common thread from both authors’ accounts is the tendency of web3 proponents to talk in the abstract. Moxie notes the tendency to focus on the future value of their systems, as a way of deflecting criticism about their current state, with the catch-cry “it’s early days still”. Molly observes a similar tendency to “switch between discussing the theoretical implementations […] and the ecosystems we have today as it suits their argument”. In both cases, those signals suggest that these systems are still bleeding edge, and best thought of as emerging.

2021: The end of software supply chain confidence

Thu, 06 Jan 2022 00:00:00 +1100

Human brains love heuristics and assumptions. Thinking about everything, all at once, is exhausting (see Kahneman’s System 1 vs System 2). So we use assumptions to simplify the problem space to something we can manage.

Cyber is full of humans, and so has plenty of these assumptions too. And a common assumption is that the security of the software supply chain is good enough. Not great, but okay. Certainly, it’s a lesser evil than known vulnerabilities, hence the frequent mantra to turn on automatic updates everywhere you can.

Unfortunately, 2021 was the year when that assumption really came under pressure — the software supply chain is under active attack, from a motivated and broadening set of adversaries. So cyber people now need to adjust our approach to defending our organisations. Let’s talk about those attacks, and then about some adjustments to defences.

Mainstream software supply chain attacks

There have been rumours (e.g., one, two, three) for years of supply chain attacks, particularly against hardware. Typically, though, this was nation-state-on-nation-state stuff — industrial spying, making use of the ability to subvert manufacturers or redirect shipping.

2021 opened, though, with a massive software supply chain attack. An adversary allegedly compromised the software development systems of SolarWinds, placing malicious code into the source of their Orion product, and pushing it out through their legitimate software update mechanism. As organisations dutifully updated to the latest (compromised) version, the malicious code was installed. From there, the attacker targeted some particular organisations of interest (Wikipedia), and executed broad-ranging campaigns of lateral movement to gain access to systems and data of interest (for example). The collateral impact was significant — lots of large organisations use the affected product, and had to rapidly undertake incident response and digital forensics to work out if they were affected, and to clean up and patch.

So, we now had malware distributed through a trusted commercial software product.

2021 continued with a criminal (as opposed to nation state) attack on Kaseya (Wikipedia). Kaseya provides a cloud service that helps organisations manage their endpoints¹, including software distribution and patching. For some subset of Kaseya’s customers, the attackers then allegedly used their access to install ransomware into those customers’ computers, taking them over and demanding payment to restore access. They also offered a sort of bulk discount: for a much larger amount they would provide a key that would restore access for all the affected organisations. Ultimately, that bulk key was made available (BBC), although Kaseya has declined to comment on whether a ransom was paid.²

So, we now had malware distributed through a trusted IT management service.

Third, there’s been an increasing set of attacks on open source components that are commonly incorporated into software.

Malicious commits – An attacker attempted to compromise the PHP language interpreter, by attacking the PHP core team’s software repository. While it was detected and blocked, if successful this could have provided a backdoor into lots of internet-facing systems, once they were updated.
Maintainer account takeover – In perhaps the most direct attacks, some attackers are targeting maintainers of common packages directly. If an attacker can gain access to these accounts, they may be able to push malware through the same Continuous Integration/Continuous Distribution (CI/CD) and build mechanisms. A good example of this was the attack on the ua-parser-js library in npm, through an attack on the maintainer by compromising his account.
Dependency confusion – Alex Birsan published a Medium article showing that they were able to inject arbitrary code into several organisations’ proprietary software. The attack relied on registering targeted, public versions of private libraries with higher version numbers. Many modern organisations use CI/CD pipelines to automatically build, test and deploy their applications, and these often pull down new versions of libraries as part of each build — because the rules about what to download and incorporate were insufficiently specific, they could be tricked into downloading and using a malicious version instead of the intended one.

So, we now have malware being distributed through open source components – whether that’s at the source, by compromise of the legitimate library, or through dependency confusion.

Finally, the log4j incidents at the end of 2021 were an extraordinary way to wrap the year. log4j is a common library for logging (a common task) in Java (a common language). It was also commonly incorporated into other software components and frameworks (e.g. Struts); one Google analysis found it was included in 4% of the libraries in Maven, at an average of five layers deep. As a result, it was incorporated in lots of software — both commercial products and proprietary code. Vendors as big as VMWare, Cisco and MobileIron issued emergency patches or workarounds; the NCSC-NL started maintaining a list of all the known vulnerable and not-vulnerable products, as did US CISA and Royce Williams. Every cyber and IT team jumped in to find and crash-patch everything they had.

So, this was a useful demonstration of how much open source there is in commercial software products, even though that’s typically opaque to the customer.

What do we draw from all this? In 2021 we had malware distributed through:

trusted commercial software products.
trusted management services.
trusted open source components.

And we had a sharp reminder about how much we don’t know about what’s embedded in commercial software.

So, it’s no longer credible to assume that the software you’re getting from others is safe or trusted. (If it ever was.)

Now what?

There’s a lot of talk about “assumed breach” in the cyber community. Usually, that means assuming that attackers have gained access to some accounts or installed some malware, and being constantly vigilant.

If you haven’t already, it’s probably time to move a step further: to “assumed compromise” in software and software components – whether commercial or open source.

As much as that’s a big challenge technically, it’s an even larger cultural change, particularly among your developers and IT ops people. Developers are implicitly taught to trust software libraries, and are often under time pressure to ship features as quickly as possible. IT ops people are taught to trust commercial software and services. Turning this around is going to require concerted effort. Particularly in re-setting the “speed vs safety” trade-off in software development.

Beyond the cultural element, here are three suggestions for what you can do right now to improve your position:

First – focus on implementing/strengthening the fundamental controls that reduce the impact of software vulnerability. By “fundamental”, I mean those things which are continuously active and are attack-independent (i.e. don’t have known-bad lists or “signatures” of any form). Perhaps the best hardening-per-dollar is egress filtering on all your systems particularly internet-facing applications, but work your way back through the rest of your systems too. If a system doesn’t need to be able to initiate outbound connections, don’t let it; and if it does, limit it to only those required. If your SolarWinds Orion instance can’t respond to an attacker’s request, you had extra time to patch it; if your application using log4j can’t resolve DNS or reach out to an external LDAP system, you’ve got extra time to patch it.

Second – get clear on what software components you’re incorporating in your software, and build automated telemetry that tells you what’s used where. That might mean instrumenting your CI/CD pipelines to record what libraries are downloaded and ensuring that the version rules are written defensively. If you’re still using manual or local builds, now is the right time to move that to a CI/CD pipeline, to build up that central visibility and control.

Third – start moving toward being able to patch everything you have within 24 hours. Yes, everything. Yes, 24 hours. Yes, that’s a huge, expensive sentence, perhaps to the point of being impractical for most organisations. But that’s where the attackers are driving us. Two things go into that:

Ensure everything you have is actively maintained, and that you can deploy upgrades. Does every application and system have a working deployment process, that can be activated on demand? While that’s almost certainly true for your critical and modern systems, it also needs to extend to all the user-developed applications, the apps that the business bought a decade ago without telling IT, and so on.
Wherever possible, automate that deployment, including regression testing. The faster, easier, and more reliable it is to upgrade, the more likely you are to be able to confidently upgrade in the face of a vulnerability, rather than having to do risk-reward calculus under stress. Again, now is a great time to migrate everything you can to pipelines.

More generally, use your purchasing power to help improve things for everyone. Reach out to your vendors and ask them what they’re doing. When will they provide a software bill of materials for the products you use, so that you know what’s in them? What are they doing to strengthen the security around their code repositories, and their build and distribution mechanisms? Have they got two-factor authentication in place for all their employee access to those systems? What quality tests are they putting in place to ensure their software isn’t subverted? And how are they contributing back to improving the security of the open source components they rely on?

2021 was the year the software supply chain security assumption was invalidated; the urgent work of 2022 is building resilience against it.

My thanks to Jordan and James for reading and providing feedback on the draft of this post.

Endpoints: servers, desktops, laptops, etc. ↩
For the sake of staying on topic, I’m not going to comment here on the interaction between cyber insurance and ransomware, but it would seem to be a factor. ↩

log4j vulnerability links, plus some interesting tools

Sun, 19 Dec 2021 11:03:00 +1100

In dealing with the log4j problem, some links that turned up in searching or that others shared.

Anchore’s grype scans container images, JAR files, etc for known-vulnerable versions of Java packages (among other things). They also have syft which generates software bill of materials (SBOM) reports. (Hat tip to the ACSC for pointing to the latter.)
Google’s security team has published an interesting article assessing the breadth of log4j usage in other packages, including the complexity of transitive dependencies: “For greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down).”
This LGTM report suggests Apache log4j 2.17 might still have some JNDI things to check.
Huntress log4j tester might be useful for quickly checking your own internet-facing systems.
@nathanqthai at Grey Noise Intelligence has published examples of attempted exploitation of the log4j vulnerability in the wild
AWS is apparently hotpatching their services, with coverage in this advisory
CyberCX NZ has a useful article with suggestions for how to handle the remaining marathon on CVE-2021-44228 without burning people out.

Some other security resources:

CVE Trends is a quick dashboard of which CVEs people are talking about on Twitter.
CISA Crossfeed is an open source external VMS/attack surface enumerator.
OWASP Amass is also for enumerating attack surface.
Rapid7 Project Sonar is scanning the internet and making the data available here.
Nuclei does non-invasive vulnerability testing.
GoPhish is an open source phishing simulation system. CISA has some tools for working with it.
This presentation is a useful intro to Velociraptor, an endpoint DFIR tool.
Microsoft provides free, time-limited virtual machines containing Microsoft Windows and Edge/IE11 for testing.

RSA Conference vendors — 2014 vs 2016

Wed, 13 Apr 2016 18:56:08 +1000

The security market is changing, and quickly. Each year, the RSA Conference hosts tens of thousands of delegates and hundreds of security vendors. In a conversation yesterday, John Stewart suggested that it might be an interesting idea to look at how the vendor population had changed over time, to get a sense for how the security market was moving.

To that end, the exhibitor lists are available online: 2014, 2016.

I’ve run a diff between the two years, and manually cleaned up duplicates that weren’t exact matches (e.g. where an ‘Inc.’ suffix had been added or removed). There may, therefore, be some errors in the data; corrections welcome to the email address in the footer.

That left 151 companies that were exhibitors in 2014, who were not present in 2016. Astonishingly, 307 companies exhibiting in 2016 were not present in 2014. The full lists are below.

Some interesting research possibilities:

What happened to the companies that left? Are they still around, and just not exhibiting? Were they acquired (e.g. Trusteer)? How many folded, and why?
How do the removed and new companies fit into a capability map of the security market? Can we infer useful market trends from the overall movements? Does this data help us start to model how consolidation within a category behaves, or when a category is likely to become an acquisition target by the security conglomerates?
The underlying data also includes each stand location – from this, we could probably infer some signal about stand cost (e.g. the very outer edge is cheapest, and the price goes up as you move inward). It would be interesting to see the migration patterns for companies year-on-year, and whether this was correlated with anything interesting (e.g. revenue). It feels like there would be a cool chart in here.
Can we infer anything interesting from the intersection of the two above? e.g. does a series of new companies in the same category appearing in the outer edge in one year indicate that a smaller number will make it into the next inward ring next year? Once a company moves outward, how likely is it to be able to recover?

Happy to contribute to a paper if anyone is interested.

Present in 2014, missing in 2016.

10ZIG Technology Inc.
21CT, Inc.
3M Privacy Solutions
6WIND
AFORE
Accellion
AccessData
Accuvant
Adallom
Agiliance
AhnLab
AirWatch
AlephCloud
Alert Logic
AlertEnterprise
AppRiver
Attachmate
Authentify
Axway, Inc.
Barracuda Networks
Beijing Zhongguancun Overseas Science Park
Bit9, Inc.
Black Lotus
BlueCat
Brainloop
CHERRY
CORISECIO GmbH
CSG Invotas
Celestix
Champlain College
Click Security
Collective Software
Coverity, Inc.
Covertix Ltd.
Cryptography Research, Inc.
Cryptomathic
CyFIR
Cyberoam Inc.
Cyvera Ltd
DBAPP Security
DaoliCloud Information Technology (Beijing) Co., LTD.
Defence Intelligence
Deja vu Security
DeviceLock
DynamiCode Company Limited
Emerging Threats
Endace Division of Emulex
Enforcive
Fiberlink
FileTrek
Fox Technologies, Inc.
Freescale
Glimmerglass Optical Cyber Solutions
GreenSQL.com
Guardian Analytics
HBGary
Halon Security, Inc.
Heshengda Information Security Technology Co., Ltd
HitmanPro
InfoExpress, Inc.
Information Security Media Group (ISMG)
Intellicus
Ionic
Ipswitch File Transfer
IronKey
KS Mobile
Key Source International
Klocwork
LOGbinder
Link11
Lumension
LynuxWorks, Inc.
MITRE
Malcovery Security
Marble Security
Metaforic
MicroStrategy
MirageWorks
Mocana
Modulo
Mycroft Inc.
NSA
NagraID Security
Nallatech Inc.
Narus, Inc.
National Institute of Standards and Technology
Net Optics, Inc.
NetCitadel
NetIQ
NetScout
New Horizons Computer Learning Centers
Norman Shark
Northrop Grumman
Oberthur Technologies
One World Labs, Inc.
PORTCULLIS
Paraben Corporation
PerspecSys Inc.
Phoenix TS
Pike Enterprises, Inc.
Portnox
PrivateCore
Procera Networks
Protected-networks.com GmbH
QIHU Technology Co., Ltd.
Quotium
Riscure North America
Riverbed Technology
SYSMATE
SafeNet, Inc.
Seccuris USA Inc.
Seculert
Secunia
Secure Access Technologies, Inc.
Shape Security
SilverSky
Sims Recycling Solutions
SmartDisplayer Technology
SnoopWall
Software Diversified Services
SolarWinds
Solutionary
Soonr
Sourcefire
SpectorSoft Corporation
StrikeForce Technologies, Inc.
Symplified
Sypris
TIBCO Software
TalariaX sendQuick
The Hacker Academy
Threat Stack
ThreatSim
ThreatTrack Security
Tilera Corporation
TrulyProtect
Trusteer, an IBM Company
Unisys
Venustech Cybervision Co., Ltd
Verdasys, Inc.
Viewfinity
Visible Statement
Voltage Security
WWPass Corporation
Watchdata Technologies
Wave Systems Corp.
Websense
Wontok
Xceedium, Inc.
itWatch
nPulse Technologies

Present in 2016, but not present in 2014.

2FA
360 Total Security
5nine Software
A10 Networks
ADLINK Technology
AHA Products Group
Abatis (UK) Ltd
Absolute
Acunetix
Agari
Ahope
AirCUVE
Allot Communications
AppViewX
Area 1 Security
Arellia
Artifex Software Inc.
Attivo Networks
Audit Square
Auth0
AuthLite
Avanan Inc.
AvePoint
Avecto
Avira Operations GmbH & Co. KG
BT
BUFFERZONE
Balabit
Basis Technology
Bastille
Beijing Huajia Technology
Beijing Venustech Inc.
Beijing Watchsmart Technologies
Biscom
BitSight Technologies
Bitglass
BittWare
Bivio Networks
Black Duck Software
BluVector
BlueTalon
Bluebox Security
Blueliv
Boldon James
Bomgar
BooleBox
Boxcryptor
Bricata
BrightPoint Security
CENTRI Technology
CYBERBIT
Cambridge Intelligence
Capgemini
Carbon Black
Carr & Ferrell LLP
Cavium, Inc.
Centre for Secure Information Technologies (CSIT)
Centripetal Networks, Inc.
Certified Security Solutions (CSS)
Cheetah Mobile
CloudPassage
Cloudera
Cloudpath Networks
CoSoSys
Colopoint GmbH
Comcast Business Enterprise Solutions - MSuite
Confer Technologies
Covata
Cradlepoint
CrowdStrike
Cryptsoft
Cryptzone
CyberInt
CyberSponse
Cybereason
Cylance
D3 Security
DBAPPSecurity
DarkMatter
DataBlink, Inc.
DataLocker Inc.
Deep Instinct
Department of Homeland Security, Science & Technology
Detack GmbH
Digital Guardian
Digital Shadows
Dispersive Technologies
Distil Networks
Dome9 Security
Druva
ECI Telecom Ltd.
ETRI(Electronics and Telecommunications Research Institute)
EZchip
Early Warning
EdgeWave
Egis Technology Inc.
EgoSecure
Encode UK Limited
Endgame
Engage Communication
Enigmedia
Exabeam
Executive Women’s Forum
Fastly, Inc.
Federal Reserve Bank of San Francisco
FinalCode
Fireglass
Flexera Software
Flowmon Networks
Forcepoint, Powered by Raytheon
Fornetix
Fortscale Security
Fox-IT
GB&Smith
Gemalto
Geninetworks
Global Learning Systems
GlobalSCAPE
Great Bay Software
Green Hills Software
Ground Labs
Guardicore
H3C Technologies Co., Ltd.
HAWK Network Defense, Inc.
Happiest Minds Technologies
Heat Software
Hexadite, Inc.
Hitachi ID Systems
Hypori, Inc.
IBASE Technology, Inc.
IDenticard
INCA Internet Co., Ltd
INSIDE Secure
IPOQUE GmbH
Idappcom Ltd.
Illumio
Illusive Networks
Inspired eLearning
IntelliGo Networks, LLC
International Association of Privacy Professionals
Interrmedia.net, Inc.
Interset
Invincea
Invotas International
Israel Export Institute
Janus Technologies, Inc.
KISA(Korea Internet & Security Agency)
KOTRA
Kalray, Inc.
KnowBe4
LastPass Enterprise
Level 3 Communications
Lockheed Martin
Logtrust
Lookingglass
Luxar Tech
Lynx Software Technologies, Inc.
MIRACL
Malwarebytes
ManagedMethods
MediaPro, Inc.
Menlo Security
MessageSolution, Inc.
Minerva Labs Ltd
Morphick Inc
NC4
NCC Group
NIARA Inc.
NIST
NRI SecureTechnologies
NSRI(National Security Research Institute)
NTT Group Security
National Security Agency
Negev Telcom
NetLib
Netskope
Netsparker
Netwrix
Nexusguard
Niagara Networks
Novetta
NowSecure
Nubo Software Ltd.
Nuix
ObserveIT
Office of the Comptroller of the Currency
One Scorpion Security
Onspring
Ontario, Canada Delegation
Optimal IdM
Optiv
Osirium Ltd
Outpost 24
PFP Cybersecurity
PKWARE
Palamida, Inc
Palerra
Palo Alto Networks
Peach Fuzzer
Penn State Univerisity
Phantom
PhishLabs
PhishLine
Plixer
Pradeo
Prelert
Prevoty
Prosoft Systems Intl.
ProtectWise
Protegrity
Protiviti
Pulse Secure
Quick Heal Technologies
Rambus Cryptography Research
Recorded Future
Red Hat
RedOwl
RedVector
Resilient Systems
Return Path
RiskSense
RiskVision (Formerly Agiliance)
Rogue Wave Software
Rook Security
SAP SE
SAS
SAVIYNT
SOTI
SS8
SaferZone
SailPoint Technologies
Savvius, Inc.
SecuGen Corp.
SecurEnvoy
SecureLink, Inc.
Security Compass
Security First Corp.
Secusmart GmbH
SentinelOne
ServiceNow
Siemplify
Silobreaker
Simeio Solutions
Skyport Systems
Soha Systems, Inc.
Sparkle Power
Sqrrl
Staminus
SuperCom
Surevine
SurfWatch Labs
Synopsys
TICTO
TRUSTe
TaaSera
TeachPrivacy
Telecom Brokers
Telefonica
Telesoft-Technologies Ltd
Terranova WW Corporation
The Media Trust
The Open Group
ThetaRay
ThreatBook
ThreatConnect
ThreatQuotient
ThreatSTOP
ThreatStream
ThreatTrack
Titan IC Systems
Titania
TrapX Security
Trusted Knight
UKTI Defence & Security Organisation
Untangle
Utimaco Inc.
VMray GmbH
Verint
ViaSat, Inc.
Votiro
Vysk Communications
Waratek
Watchful Software
WebRAY(BeiJing)Tech Co.,Ltd.
Wheel Systems
WhiteHat Security Inc.
WhiteSource
Whitewood
WinMagic
WireX
X15 Software
Yubico
Zenedge, Inc.
Zentera Systems
Zertificon Solutions
Zhongguancun Overseas Science Park
Ziften
Zimperium
Zonefox
digitronic computersysteme gmbh
gateprotect GmbH
iSIGHT Partners
iovation
itWatch GmbH
secunet
tyntec
whiteCryption