This is painfully accurate. A chain is really only as strong as its weakest link :/
With 30 years of daily experience in this field, I am ashamed about how we fail Matthew & my mother in the sense that they can still not just enjoy the internet and open random emails without one of us blaming them for how stupid they are.
I think we need to start very early. There should be more mandatory comouter science and information security classes at schools because we are all confronted with these topics everyday.
Most people can work systems such as washing machines, vacuum cleaners and so on, the problems arise when the internet (or other forms of connectability) comes into the picture. But the reality is that most such systems will probably soon be connected in some way, so the challenge grows.
So I think it is very important that we push for more information/education instead of going into the direction of more locked down, closed off and proprietary systems because these can easily "not respect" the end user.
It’s like we’ve given every Tom, Dick and Harry a F1 supercar then we blame them when they crash the thing. The mistake is ours for not making better security models. Desktop apps should be sandboxed by default, and isolated like we isolate phone apps. For all the justifiable fear people have about apple’s control over what software can run on their machines, I think the app sandboxing and signing security model they’re working towards is the right one for 95% of computer users.
They don't understand the concept of files as separate from applications. They just don't. They understand the concept of sharing -- that seems to be intuitive enough -- but not of files as objects in themselves.
A system which works this way would, of course, be completely rage-inducing to myself.
I think we need to all realize that most people aren't cut out for computer science, per se, but most people are cut out to learn to responsibly use a computer.
As a matter of fact though, the same people do _not_ use computers responsibly. What do you do, then? Metaphorically jail them?
There are lots of areas where as humans, it's easy to reach a "sufficient" level, _and_ the dangers of an insufficiency are well known. Punishments or strict measures just don't work.
Everybody knows that they can be sufficiently and with little effort fit, but especially, that unsufficient fitness leads to sicknesses and earlier death. In this sense, which punishment can be worse? Yet, this doesn't work.
Leaning to driving is not the correct analogy. Almost everyone can use a mouse or a touch screen to operate a computer.
Even better is that the company should have its own internal ordering system.
This always becomes a war where the seller wants you to send orders 1 way, and the buyer wants to send all orders another way.
It would be really cool to have an invoice format that contains payment and tax information in a machine readable way and a way to send that information around with a verifiable channel.
pdf.js lacks capabilities to extract the XML or verify signatures, so the usual way will be to use Acrobat Reader or the usual bunch of "industry-standard" invoice-processing crap that now suddenly has to deal with malicious input.
The idea to do it differently might be nice in theory, but is lacking a smooth way to change over from the old paper-invoice ways. PDF will be the thing for some decades and we will have to deal with it.
This means that while you might be able to use something other than PDF for the human-readable part, I don't think anything other than PDF will be used. All the other stuff (XML with embedded SVG or PNG, Word, plaintext) will have acceptance problems in one form or the other.
EDI is big business to big business, as evidenced by you mentioning SAP. There, you may be completely right, I don't know.
A technique we used at Blekko (and hopefully you guys do as well) was logging/tracing statistical traffic flows for normal cluster operations such that we could alert on atypical traffic (which in our case meant something was likely kinda broken but limping along and needed to be fixed/replaced.). We also didn't have to deal with APTs before we were acquired so the stakes were way lower.
Agreed that getting hacked is inevitable if the prize is worth it, always interested in adding new ways to instrument the world to detect sniffing or attacks.
I guess one benefit might be to push the development of new detection techniques to detect the underlying implementation of these tools.
- The CFO doesn't understand why we need separate server infrastructure (and the associated licensing and maintenance costs) for accounting and engineering.
- Software vendors can't answer the most basic questions about how their software communicates to allow network ops to build reasonable access control lists for network segmentation.
- The network gear doesn't have sufficient horsepower to do wire-speed stateful packet filtering because, apparently, that's still an exciting new idea in 2020, and we can't slow everybody's access down.
- Individual departments have end-run IT by using "cloud" offerings that effectively bridge different segments of the network together at layer 7.
- Everybody has to be able to open their email and click random links on any PC.
The problem with any defence based on filtering is that first you have to decide what to filter. In an enterprise-scale network, this is not an easy problem, despite the number of shiny and expensive tools available that are selling the hope that it is.
Individual departments have end-run IT by using "cloud" offerings that effectively bridge different segments of the network together at layer 7.
This might be the most challenging problem for modern IT security, perhaps along with BYOD. The software and equipment accessible by staff might no longer be fully controlled by the organisation. That changes the emphasis for IT security from "just" securing your own software and systems to also somehow securing your data against unauthorised transfer to other systems. And this is a hugely complicated problem with (at least) technical, legal and management dimensions.
If the networks were air gapped, it wouldn't be Matthew's fault. Someone who had access to the engineering network would need to screw up. Which is of course perfectly possible—engineers make mistakes too. (Furthermore, if they were hacked by a nation state... for all we know it really could have been done without any user action at all.)
Either that or one of the Siemens engineers who showed up at the plant's laptop was infected in anticipation of them showing up there to fix stuff.
Even if you got all of the issues caused by e-mails figured out, somehow you have to transfer them from one network to another. You'll either have to poke holes into your firewall or use USB sticks.
My point is: even in airgapped networks you usually want to exchange some data. The moment you want to exchange data, you have a path where a virus can be smuggled in.
What other security features claim that performance?
If you are doing penetration testing and basic security work, there is no value in having private tools. It becomes important in red team work because you are trying to emulate a real attacker that has access to non-public tools.
If they didn’t have a binary that looked reasonably different to those that already exist, then it would instantly get triggered. It is worth noting that there are tools to obfuscate sourcecode/bins.
Microsoft provided him a nifty protocol for that.
> Mimikatz first became a key hacker asset thanks to its ability to exploit an obscure Windows function called WDigest. That feature is designed to make it more convenient for corporate and government Windows users to prove their identity to different applications on their network or on the web; it holds their authentication credentials in memory and automatically reuses them, so they only have to enter their username and password once. While Windows keeps that copy of the user's password encrypted, it also keeps a copy of the secret key to decrypt it handy in memory, too. "It’s like storing a password-protected secret in an email with the password in the same email," Delpy says.
https://www.wired.com/story/how-mimikatz-became-go-to-hacker...
Matthew in accounting shouldn't have permission to run an untrusted binary.
As often.
And depending on the resources of the hacker, the email could be stylised just for him, talking about something important that's (perhaps something bad) happening now and the notBoss is telling him to check this months info, and kindly providing him with a pdf that Mathew hastily opens with his latest version of Adobe Acrobat with a zero day vulnerability that hasn't been discovered yet.
It could also be literally anything.
Executable files are blocked by pretty much all corporate e-mails systems. Zero-days for PDF viewers are rare. After all, most hacking attacks are things like ransomware campaigns, where everyone is a potential victim and phishing mails are sprayed all over the internet. A zero-day would be burnt pretty quickly.
However, many users legitimately need office macros and also need to open office documents to collaborate with contractors or customers. Many times, the phishing mail comes from a legitimate address because the other company has been compromised already.
The solution would be to only allow signed macros, but depending on the size of the organization, that can be costly.
^ This is the solution I have been mulling if and when I am responsible for an org where security is kinda important. Sure, iOS is still hackable, but hopefully we put more hindrance steps between the attacker and the org, and move the exposure more to the cloud services (like box). Curious if this is feasible.
0: https://www.amazon.com/REDDOTMOBILE-Detachable-Magnetic-Ligh...
Am I missing something?
For example take the tool mimikatz [1], which is publicly available and well known. It can dump stored passwords out of Windows memory. But if you download mimikatz and try to run it every single antivirus/endpoint protection solution will light up like a christmas tree. However, the underlying technique isn't being blocked - just the specific implementation. This is why we build our own tools: to demonstrate to defenders that while they are blocking a specific implementation they have not addressed the underlying vulnerability.
I do want to call out FireEye for doing an amazing job recovering from this situation. They did the responsible thing and released fingerprints [2] that could be used to detect every single one of their tools. They effectively burned their entire catalog and put them in to the class of "public" tools that are easily identified. I've browsed over the list of signatures and didn't see anything that popped out as giving a malicious attacker any advantage other than saving them work of building it themselves (of course I don't have access to look at the actual tools so YMMV).
Also, everyone gets hacked. No matter how good you are or how many cyber security engineers you have on staff... there is still Matthew in accounting that will open that invoice attachment so he can pay it.
1. https://github.com/gentilkiwi/mimikatz 2. https://github.com/fireeye/red_team_tool_countermeasures/tre...
Edit: To be clear I do work on an internal red team - we hack ourselves. I don't work for FireEye or a competitor.
Edit 2: Don't pick on Matthew. :)