When Security Takes a Backseat to Productivity
krebsonsecurity.com
krebsonsecurity.com
Why does anybody assume they would be able to protect their systems even if it was their main priority?
The CIA works on cyber-weapons designed to surveil countries, disable infrastructure, and destabilize governments. How capable and well-funded should a person or country need to be to destroy an economy or destabilize a government by stealing the CIA's weapons? $1B, $10B, $1T? A team of 1,000, 10,000, 1,000,000 specialists?
I think most people would probably agree that $1B is a lower bound for nation-destroying capabilities. You could hire a team of 100s-1000s of offensive security specialists full-time for 10 years with a budget of $1B. Does anyone know of any system or organization in existence that would even be willing to claim they can stop of a team of 1000 dedicated offensive security specialists working full-time for 10 years with a $1B budget let alone put it in writing or have evidence to back up that claim? What is the highest you have heard? Is it even in the general ballpark? I have personally never talked to an organization willing to claim a number higher than $1M and willing to put their money where their mouth is.
If nobody is even willing to claim that they can provide an actual defense, let alone having the extraordinary evidence required to backup an extraordinary claim of $1B, why is there any reason to believe that the CIA would be able to protect themselves even if they prioritized the problem?
And FTA "Segmenting one’s network", even my shoddy underfunded local health dept has implemented that one. The CIA didn't even do the basics here.
Like, imagine a world where the Army made tanks out of tissue paper. You could say, "Look at these clowns. Don't they know regular paper provides better defense than tissue paper.". While true, it does not really matter since if the best armor available is paper, every strategy should probably avoid depending on tanks.
My point is about looking at OBJECTIVE requirements and evaluating solutions against them. At a basic level this boils down to two questions:
1. What is the NECESSARY level of security?
2. Can anybody achieve the NECESSARY level of security?
If the answer to 2 is no, then the system MUST NOT be used/created.
I guess this doesn't apply to unique assets like the CIA, but for your regular old e-commerce firm, you can have defences that wouldn't stand up to a sustained, targeted attack by state actors, but still make regular hackers go steal somebody else's DB of customer details.
I agree that not everybody needs to be able to withstand an attack by state actors. It is up to the involved and affected parties to choose the level of security needed. However, the highest level of actual security I have heard from people is ~$1M and I would be hard pressed to find any appreciable system in a moderately-sized business where the negative consequences would be as low as ~$1M. Frankly, $1M is chump change in the commercial world. If that is all it takes to compromise nearly any system or organization in the world, then a sizable fraction of the people reading this comment and around 46,800,000 people worldwide have the personal resources to compromise any system in the world. That is terrifying.
Maybe the marketplace just doesn't value security? Customers seem happy to give away all their data to Google/Facebook for free. Equifax got completely and thoroughly owned but it hasn't seemed to cost them anything. Zoom is a security nightmare but keeps getting more popular.
Companies aren't going to value security until the lack of it starts to sting their stock price.
If you want security to be a first class constraint, you must make security features extremely easy to use and ergonomic above all else (even above being secure!).
Nobody is going to willingly agree to abandon their productivity or flexibility for your security tool or policy. If you make them choose, security will lose 100% of the time, forever, in every walk of life.
You need to stop viewing it as if you need people to sacrifice for security and instead design for ergonomics and usability as the obsessive, #1 priority.
This is why consumer password managers succeed (and help people to be more secure!) but internal security teams can’t get anything done in private companies.
Your first responsibility is to make something your users want and like to use, period. After you solve that, then, without disrupting usability, you can modify it to actually adhere to security constraints and achieve other results.
If I see that a company has an internal security team my first question is, where is the product manager?
If you don’t treat internal security tooling like you’re delivering a product, then you’re done. Just go home and watch Netflix because you’re not solving security problems.
That's definitely not right.
The correct security design is that when things aren't secure you fail entirely. This will sometimes be very annoying but the temptation to prefer not failing leads to disaster. Instead an organisation that prioritises security must dedicate resources to resolving the actual security problem as a priority because it is very annoying.
For example 'thisisunsafe' and its predecessor 'badidea' are indeed, unsafe and a bad idea. The correct design is to simply fail instead. Which organisation do you think gets successfully phished with invalid HTTPS certificates - the Chrome embracing organisation that has taught people they can just type "thisisunsafe" or the one where everybody uses Firefox and it brick walls when HSTS denies access?
> Nobody is going to willingly agree to abandon their productivity or flexibility for your security tool or policy.
This is almost correct. Humans are very lazy. They will give up their productivity or flexibility for your security tool or policy if it's easier than the alternative.
For example when your users are trying to give their credentials to bad guys, you need to make this so difficult they give up.
You might think you can train your users not to want to give their credentials to bad guys, but this is unlikely to be successful enough to bother. Instead get to a place where your users, even though they really want to help the bad guys, just can't see an easy way to do it.
They may even file a helpdesk ticket because they genuinely don't realise what they're trying to do would be a very bad idea. Try not to be smug when responding to the ticket.
Yikes, this is extremely wrong. Security failures should be proportional to the actual cost and consequences.
On top of this, you can’t just fail systems in a business. You’ll lose all your customers and go bankrupt. On the other hand, you _can_ allow security vulnerabilities to continue existing. Sometimes you might lose customers or face legal consequences, so you might _have to_ address those security situations, but they are in the rare minority of all security issues overall, many of which you just need to apply expected value thinking towards and treat like any other trade-off.
Security is a resource to be traded off against other concerns, not an absolute necessity.
That's wonderful for Nostradamus, but everybody else is obliged to operate without knowledge of the future. What will the actual consequences be of bad guys being able to send email from the VP Asia Pacific's account to the CFO's office five minutes before close of business?
Maybe nothing right? Or maybe an "urgent cash payment" of $48M to secure a take over deal vanishes into a maze of international accounts never to be recovered...
Security is a special problem because you have unknown sentient adversaries. You completely lack intelligence about the adversary because you don't even know who they are. Don't think about security decisions the way you'd think about decisions like whether to hire a back-up venue in case the company picnic is rained off.
I’ve had US government customers take 3 months to review a CR to connect two systems. I’ve been tossed non-sensical documentation and told to fill it out without any help, a process that can take literally weeks of person time. And I’ve seen security teams cripple critical business functionality for, at best, marginal security gains.
In environments where things like the above are happening you start users and even business organizations rebel, they start operating outside of the it systems (txt message driven shadow business processes are common) and IT broadly and security specifically begin to be seen as the enemy.
How to fix this? Well one, i think security teams really need to focus on making themselves aids to everyone else rather than traffic cops. One model I like is to embed security team members in any development process or acquisition effort as team members, with the expectation these v-team members actually deliver work, including advocating for the team with in the security process and creating any security artifacts. That’s expensive, so they’ll have to be some cross billing set up or something, but it’s worth it IMO.
Regardless, security that reduces an organizations ability to do its mission runs the risk of getting avoided altogether.
The first priority needs to be to make it easy and obvious to do the right thing.
Trying to make rules to forbid doing something insecure isn't helpful at all. If I need to do something and the only way I know how is the unsafe way, there's a big risk I'll pick that way. Unfortunately, it seems that security work is often just about trying to stop people from doing things, not helping them to do it the right way.
- if you have engineers with previous implementation experience on HITRUST or similar, it can be done. But it's hard to retrofit if everything that's installed is stale.
- otherwise you end up with "paper certifications" without the engineering to support it. That works for a while, but eventually becomes a problem if an on-site audit is scheduled.
lie isValidTLSCert(){return true;//suuure}
Today is is mostly a configuration issue. Of course you will never be praised for the security of a solution. If something bad happens security quickly becomes the most important thing of course.
If hollywood did one thing well - it was to inspire in me a misplaced faith in the competency of security/government institutions.
Things like "Pet names and mother's maiden names are common security questions, so maybe lets not store those in our employee info database" are valid security considerations. And of course they make the employee database slightly less useful.
15+ Years ago QinetiQ used to solder up the usb ports on its lap tops and that's for those working on avowed jobs, not the Secret Squirrel ones.