21–30 of 83 posts
That said, one of the things that caught me off guard is the dressing down of the head of security by a member of the board. More or less, they were told what they did was clog the flow of useful work. The message conveyed is similar to this post.
Other than the myriad of problems with passwords that NIST has killed in competent circles, what are some other "useless controls"?
Just because this is my favorite soapbox - anyone that has to deal with passwords should go read NIST SP800-63B:
https://pages.nist.gov/800-63-3/sp800-63b.html
I was kind of shocked by just how gosh-darned reasonable it is when it came out a couple of years ago. It's my absolute favorite thing to cite during audits.
"Are you requiring password resets every 90 days?"
"No. We follow the federal government's NIST SP800-63B guidelines which explicitly states that passwords should not be arbitrarily reset."
I've been pleasantly surprised that I haven't really had an auditor push back so far. I'm sure I eventually will, but it's been incredibly effective ammunition so far.
When we write software, we answer three questions: "What?", "How?", and "Why?".
We write out the answers to "What?" and "How?" explicitly as data and source code. The last answer, alas, can never be written; at least, not explicitly. When we are good programmers, we do our best to write the answer Why implicitly. We write documentation, tutorials, examples, etc. These construct a picture whose negative space looks similar enough to live in Why's place.
No matter what, the question "Why?" is always answered. How can this be, if that answer is never written? It is encoded into the entropy of the very act of writing. When we write software, we must make decisions. There are many ways a problem could be solved: choose only one solution. A chosen solution is what I call an "Assumption". It is assumed that the solution you chose will be the best fit for your program: that it is the answer your users need, or at least that it will be good enough for them to accomplish what they want.
Inevitably, our Assumptions will be wrong. Users will bring unique problems that your Assumption isn't compatible with. While you hoped your Assumption would be a bridge, it is instead a Wall.
The Walls of Assumptions in every program define a unique maze that every software user must traverse to meet their goals. Monolithic design cultivates a walled garden, where an efficient maze may fail entirely to lead the user to their goal. Modular design cultivates an ecosystem of compatible mazes that, while less efficient, can be restructured to reach more goals.
---
The eternal hype around Natural Language Processing and Artificial Intelligence is readily explained with this metaphor. The most powerful feature of Natural Language is Ambiguity. Ambiguity allows us to encode more than one answer into data, which means we actually can write the answer to Why; we just can't read it computationally. Artificial Intelligence hinges on the ability for decision to be encoded into software. I'm not talking about logical branches here: I'm talking about the ability to fully postpone the answering of Why from time-of-writing to runtime.
---
For the last year or two, I've been chewing on a potential solution to this problem that I call the Story Empathizer. So far, the idea is too abstract; but I still think it has potential.
I just read the book The Phoenix Project. It's over a decade old so some of the principles are obvious/quaint at this point, or perhaps not quite as applicable. That said, one of the things that caught me off guard is the dressing down of the head of security by a member of the board. More or less, they were told what they did was clog the flow of useful work. The message conveyed is similar to this post.
Similar to seeing IT as a cost rather than a benefit.
This is quite a simplification. There are a lot of useless/dubious controls out there, but the problem is rather the contradiction between security pragmatism and compliance regimes. #### Government: I need a service. Contractor: I can provide that. Government: Does it comply with NIST 123.456? Contractor: Well not completely, because control XYZ is ackshually useless and doesn't contribute-- Government: hangs up
I think it's fine to implement a useless control to get a customer. Just don't pretend that you're doing it because it is a useful control, pretend that you're doing it because jumping through that hoop gets you that customer, and "we're a smaller fish than the government". Especially with the government (especially if it's the USA…) there are going to be utterly pointless hoops. I can pragmatically smile & jump, … b…
Earlier quoted context omitted.
I bumped into controls mandating security scans, when people running the scans don't need to know anything about the results. One example prevented us from serving public data using Google Web Services because the front-end was still offering 3DES among the offered ciphers. This raised alerts because of the possibility of Sweet32 vulnerability, which is completely impractical to exploit with website scale data sizes…
"Why do we have to do X? Because we have to do X and have always had to do X" is a human problem coming from lack of expertise and lack of confidence to question authority. It's a shame, your story isn't unique at all.
Like, IT sec does not trust employees. This burns absurd amount of money day in, day out, due to broadly applied security policies that interfere with work.
Like, there's a lot of talk about how almost no one has any business having local admin rights on their work machine. You let people have it, and then someone will quickly install a malicious Outlook extension or some shit. Limits are applied, real-time scans are introduced too, and surely this inconveniences almost everyone, but maybe it's the right tradeoff for most of the org's moderately paid office workers.
But then, it's a global policy, so it also hits all the org's absurdly-highly paid tech workers, and hits them much worse than everyone else. Since IT (or people giving them orders) doesn't trust anyone, you now have all those devs eating the productivity loss, or worse, playing cat-and-mouse with corporate IT by inventing clever workarounds, some of which could actually compromise company security.
In places I've seen, by my guesstimate that lack of trust and ability to issue and monitor exceptions to security policies[0] could easily cost as much as doubling the salary of all affected tech teams.
As much as big orgs crave legibility, they sure love to inflict illegible costs on themselves (don't get me started about the general trend of phasing out specialist jobs and distributing workload equally on everyone...).
--
[0] - Real exceptions, as in "sure whatev, have local admin (you're still surveilled anyway)", instead of "spend 5 minutes filling this form, on a page that's down half the time, to get temporary local admin for couple hours; no, that still doesn't mean you can add folders to exclusion list for real-time scanner".
Most likely, useless controls exist because the company thinks they are good enough for the business and there's no incentive to improve or replace them.
I just read the book The Phoenix Project. It's over a decade old so some of the principles are obvious/quaint at this point, or perhaps not quite as applicable. That said, one of the things that caught me off guard is the dressing down of the head of security by a member of the board. More or less, they were told what they did was clog the flow of useful work. The message conveyed is similar to this post.
That sounds like a very valid complaint, too rarely heard these days.
People seem to forget that security always comes at a cost, so security decisions are always trade-offs. The only perfectly secure system is the one that does absolutely nothing at all.
Does forcing everyone's machine to run real-time scans on all file I/O improves our security more than it costs us in crippling all software devs? Maybe. Being on the receiving end of such policies, including this particular one, I sometimes doubt this question was even asked, much less that someone bothered to estimate the expected loss on both sides of the equation. Ignoring the risks doesn't make them go away, but neither do costs go away when you pretend they don't exist.
I think the "chimps in a cage" needs some followup experiments to tell the whole story -- replacing the banana with a much higher value reward, or placing another water hose which fires if chimps stopped trying to reach the reward ;) Most likely, useless controls exist because the company thinks they are good enough for the business and there's no incentive to improve or replace them.
I’ve been thinking about this topic thru the lens of moral philosophy lately. A lot of the “big lists of controls” security approaches correspond to duty ethics: following and upholding rules is the path to ethical behaviour. IT applies this control, manages exceptions, tracks compliance, and enforces adherence. Why? It’s the rule. Contrast with consequentialism (the outcome is key) or virtue ethics (exercising and a…
I work at medium to large government orgs as a consultant and it’s entertaining watching beginners coming in from small private industries using - as you put it - consequentialism and virtue ethics to fight against an enterprise that admits only duty ethics: checklists, approvals, and exemptions. My current favourite one is the mandatory use of Web Application Firewalls (WAFs). They’re digital snake oil sold to organ…
Aren't these still useful for figuring out what happened if you're hacked?