Security software is just software, subject to all of the same problems as any other type of software. And like so much of the software we find in the enterprise, security software has some predictable characteristics:
While participating in some industry analyst research, I was asked how I’d walk someone through and connect these concepts. This is a paraphrased version of the talk track (with some visuals based on prior work).
Phil Venables published a helpful collection of ways that risk and cybersecurity leaders can share their successes, ideally on an ongoing basis. His working theory, which I believe is correct, is that we’re not great at this. And as a result, many of our peers only hear from us when things go sideways, which leads to a variety of problems.
A collection of websites and projects that I’ve used in an attempt to track upcoming information security (infosec) or cybersecurity conferences, including call for papers (CFP) deadlines.
There are a variety of cybersecurity product categories and activities intended to reduce the likelihood that an adversary finds and successfully exploits a vulnerability, resulting in an intrusion (and ultimately a breach):
In the course of reviewing a number of published threat models, it became apparent that there is not (nor does there need to be) any standard output format, even given the same methodology (e.g., STRIDE).
An interesting aspect of cloud-related threat models is that cloud-based threats must take into account shared responsibility models that are specific to each cloud provider and service.
I don’t know much about threat modeling, except that as long as I’ve been working in cybersecurity, we’ve been asking people about their threat model, telling them to do threat modeling, and in the worst cases using greedy threat models to convince folks that they should prioritize things that they probably should not.
Information asymmetry is the root cause of every breach. Your adversary knows something that you do not.
In reviewing security firms’ 2022 threat data, a subset of these include insight into the initial access vectors leveraged most frequently in successful intrusions. This is a summarization of findings based on their reporting.
This model attempts to explain the relationship between visibility, observability, detection, and mitigation, which are closely related and important to understand when implementing any information security or cybersecurity program.
For some time now, I’ve been considering a hypothesis that the future of cybersecurity is some form of vertically integrated set of products, services, and insurance. This won’t represent emerging or niche cybersecurity products and services, but will bring actuarial rigor to identification and measurement of the outcomes that cybersecurity vendors claim to provide, and so it will represent the subset of offerings that provide consistent, provable value (i.e., things that reliably mitigate high impact threats). The primary consumer benefit will be a faster path to implementation of a plenty good enough cybersecurity portfolio for a large percentage of organizations.
Incidents may be one of the best measures of maturity, effectiveness, and progress in any highly operational environment, including but not limited to security operations and technology operations (including site reliability engineering, or SRE). However, incident management done right can be an invaluable tool that you can point at virtually any problem- or failure-prone system to make it better.
The concepts of visibility, observability, detection, and mitigation are foundational to cybersecurity–security architecture and detection engineering in particular–and technology operations in general. They’re useful for communicating at almost every level, within technical teams but also to organizational peers and leadership.
This Google Sheets template aims to make it easy to perform simple, measurable testing of MITRE ATT&CK techniques using Atomic Red Team or an adversary emulation solution of your choosing.
It’s 2023 and security firms are starting to release findings from 2022 threat data, notably their lists of the most active, impactful ransomware groups.
The Vegas security conferences used to feel like diving into a river. While yes, you networked and made deals and talked about exploits, you also felt for currents and tried to get a prediction of what the future held. A lot of this was what the talks were about. But you went to booths to see what was selling, or what people thought was selling, at least. But it doesn’t matter anymore what the talks are about. The talks are about everything. There’s a million of them and they cover every possible topic under the sun. And the big corpo booths are all the same. People want to sell you XDR, and what that means for them is a per-seat or per-IP charge. When there’s no differentiation in billing, there’s no differentiation in product.
The DFIQ project (GitHub, website) is an open source collection of questions that analysts should ask during certain types of investigations. There’s a simple tagging system that allows a unique question to be associated with platforms, primitives like file or network knowledge, and of course MITRE ATT&CK techniques. Questions are used in the context of scenarios, which are effectively types of incidents.
This is textbook example of the type of input you’d apply to an exposure management process:
From Byrne Hobart at The Diff, a list of scaling bottlenecks often encountered by startups: Recruiting, decision-making, management, and more.
If there’s an article-length version of Atomic Habits, published years prior to the best-selling book, this might be it.
A simple, elegant application from Darius Kazemi (GitHub, Website) that runs locally via your web browser and takes as input:
From Gwendal Le Coguic (@gwen001 / @gwendallecoguic), offsec.tools is a fairly wide-ranging collection of offensive security tools. At the time of publication, it includes close to 700 tools, though some very popular free tools (e.g., mimikatz, impacket) are missing, and the project’s appetite for cataloging commericial tools (e.g., Pegasus, FinFisher, etc.) is unclear.
From the Carnegie Endowment for International Peace:
Phil Venables published a helpful collection of ways that risk and cybersecurity leaders can share their successes, ideally on an ongoing basis. His working theory, which I believe is correct, is that we’re not great at this. And as a result, many of our peers only hear from us when things go sideways, which leads to a variety of problems.
LastPass was breached in August, and has since updated their breach disclosure several times, each update just a little bit worse and more concerning than the last. Unfortunately, for a business with a large consumer customer base, it’s almost impossible to use these disclosures to determine whether LastPass should be trusted. For security practitioners, it’s much eeasier:
The Open Source Security Index tracks the most popular and fastest growing open source security projects on GitHub. This project is the brainchild of Chenxi Wang of Rain Capital fame.