How to evaluate a cybersecurity vendor's ML claims even if you don't know much about ML (thread).
1) Ask them why they didn't solely rely on rules/signatures in their system -- why is ML necessary? If they don't have a clear explanation, deduct a point.
2) Ask them how they know their ML system is good. Where does their test data come from? How do they know their test data is anything like real life data? How do they monitor system performance in the field? If their story isn't convincing, deduct a point.
3) Ask them where on Wikipedia you can read more about the approach they took. If you can't read about it on Wikipedia, ask them where their paper is in the peer-review and on arXiv. If the paper doesn't exist / is a "trade secret", deduct 3 points
4) Ask them why they didn't take a simpler approach than the approach they took. If they can't explain, deduct a point. If they say they tried other, simpler approaches, but can't show comparison data, deduct a point.
5) If they're now down a few points, ask them if they'd like to fess up and say they're really mostly just using rules and claiming to use ML to satisfy investors and industry analysts. If they fess up and then describe a solid rules-based approach, give 'em a point or two back.
6) If they claim "zero false positives!" or "zero false negatives!" don't deduct any points, just end the Zoom call.
7) Ask for examples of attacks the system missed and explanations as to why. Deduct points if they can't think of any misses or can't easily produce a story about their system's known weaknesses.
8) Now ask for a live demo where you control the inputs and test the system on both malicious and benign data. Give them some points depending on how their system performs on a test that you yourself have designed.
You don't have to know much about ML to use something like the system I'm pitching here. Just don't get intimidated by obfuscation attempts from the vendor (common tactic) and keep pressing for clear and convincing answers.
Also, what do you do when you have your final point count? Depends on lots of other factors, including the other tech that the vendor is selling with the ML system, and variables like price and the overall value of the technology in your ecosystem.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1\ Surprisingly, you could build a very mediocre PE malware detector with a single PE feature: the PE compile timestamp. In fact, I built a little random forest detector that uses only the timestamp as its feature that gets 62% detection on previously unseen malware at a 1% FPR.
2\ The timestamp field poses a low-key problem for attackers. If they leave the compiler-assigned value they reveal telling details. If they assign a concocted value, their tampering can make them easier to detect. Here's an 'allaple' malware set's random, insane timestamps:
3\ Now let's look at a big malware dataset's compile timestamp behavior. Notice the straight horizontal lines. Those are unique polymorphic hashes reusing the *same* compile timestamp month after month. Also, notice the number of insane back-to-the-future timestamps.
1/ Here's a thread on how to build the kind of security artifact "social network" graph popularized by @virustotal and others, but customized, and on your own private security data. Consider the following graph, where the nodes are malware samples:
2/ What you're seeing are relationships between samples from the old Chinese nation-state APT1 malware set provided by @snowfl0w / @Mandiant (fireeye.com/content/dam/fi…). The clusters are samples that appear to share C2, based on the kinds of relationships shown in the image here:
3/ In graph vocab, the object above is known as a "bipartite graph", which has the following structure: there are two sets of nodes, malware samples and domains, and nodes in either set can only connect directly to the *other* set.
Thread on cognitive biases in cybersecurity I've noticed:
Maginot Line: you got breached by an impersonation attack, so you go buy an anti-impersonation solution and assume you're much safer. Sort of like checking people's shoes at the airport.
Survivorship/reporting bias: You treat statistics on breaches that have been reported publicly as representative of the threat landscape, when the most successful breaches go undetected.
Just-world bias / moral luck bias: you believe org X's security failings are uniquely terrible because they got publicly breached, even while other orgs with similar postures (including yours) haven't been breached, simply due to luck.