Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I simultaneously agree and disagree with him.

I think he's wrong because security is increasingly critical, but I agree with him because I can't stand (most of) the infosec profession.

The vast majority of infosec gives zero thought to any concern other than security, resulting in systems that are insanely complex with incredibly poor user experience. Not only does this break everything else, but it's bad for security in the long run. The typical security solution is something that makes it so hard for people to do ordinary work that they either disable it entirely (e.g. SELinux) or work around it (tunneling through aggressive firewalls, etc.) and defeat the whole purpose.

I worked in a research institution once where some departments had people whose informal job description (I was told) was to "help work around security so we can get our work done." If you worked with security, they'd put up so many road blocks and say "no" to so many things that months and months could go by without a single thing being accomplished. There was a whole culture of literally conspiring to ignore and sidestep the security department. People kept doing this even after we got hacked, arguing (again explicitly) that the cost of complying with infosec was greater than the cost of the hack.

Infosec is largely a ghetto populated by people who only think about one thing, and who think that one thing is the sexist, coolest, most important thing in the entire world. There are other such ghettoes and they all suffer from similar sorts of problems.

I firmly believe that almost nothing can be done well without whole system thinking. You have to look at the entire context of a system, not just the one thing you're building or optimizing. Think about the system from technical details all the way up to how users will interact with it on a day to day basis. A good starting point is to look at whatever you're building and ask "how annoyed would I be if management foisted this on me?" If the answer is "very annoyed," your system has horrible UX.

This isn't the only case where I simultaneously agree and disagree with Linus. Another notable one is C vs C++. Short version: I think C++ is fine and makes it a lot easier to do many things, but anyone writing C++ should have YAGNI and KISS tattooed on their forehead. As with many other "powerful" multi-paradigm languages it takes discipline to avoid over-using the language's features, and most programmers unfortunately have the opposite tendency. They over-abstract and over-engineer as if they're trying to show how clever they are.



I'm from infosec, and I understand your point. However let me provide the infosec side of the story.

Any infosec veteran can tell you that defense is so much harder than offense. If you defend a system you need to be perfectly vigilant, know all the threats, have full knowledge about _everything_ that goes on inside your company/network, you can not let a _single_ system be compromised because once "they" have a foothold inside everything is possible.

Some examples I have seen over the years include dropped usb sticks in employee parking lots, internal taps on traffic disguised as (functional) laptop adapters, bugged phones, hacked printers punching holes in the firewall, mass spam emails that _someone_ is guaranteed to click. And that's just getting _inside_ your network.

Let me ask you, would you open an attachment sent to you by a coworker? Would you ask a "coworker" who's not wearing hier/her company badge/id to identify him/herself? Would anyone notice an abandoned nondescript black box plugged into the wall somewhere?

If you answered any question with "no" I'd say your security is not up to snuff, but then that's my job.

This is why infosec is so pervasive in everything that even comes near to computers these days. No chance should be given to the attacker, no matter how trivial it may seem and no matter how _inconvenient_. Security should be inconvenient to the point of almost preventing you getting any work done, because anything less is sure to fail you when you need it most.

Just my two cents ;)


I both agree and disagree. :)

The problem is that nobody's looking for deeper solutions to security problems. For most vendors, even enterprise and well financed ones, security is a bolt-on afterthought (along with privacy, a form of security). For most infosec people, infosec is a game of patching dams full of holes with chewing gum. (Or whack a mole if you prefer that metaphor.)

These two problems are related in that there's a feedback loop at work -- vendors don't prioritize security because infosec is bad for UX, and infosec is bad for UX because vendors don't give them anything to work with other than blocking things and hole-patching. There's also the reverse feedback loop in that vendors don't build in good security because infosec isn't delivering well thought out and deep innovations that don't wreck UX.

The whole situation is utterly pathological IMHO.

I gave a mostly theoretical talk on this at a conference called border:none last October in Germany:

https://www.zerotier.com/misc/BorderNone2014-AdamIerymenko-D...

[warning: big honkin' PDF]

I don't consider the ideas there entirely baked and they deal almost entirely with the networking domain, but I think the same "race against ourselves" argument applies to other aspects of infosec.


I've been putting some thought in some deeper solutions, and while I don't have a solution I do think I have some inkling as tho were the problems come from.

The real problems with security are obviously not inherently tied to computers. In very _very_ abstract terms I think security is very closely tied to decision making systems, not in the sense of talking with others in boardrooms (although this constitutes a decision making system), but the decisions you make unconsciously to achieve some goal. The type of decision making I'm getting at now is very well explained by Eliezer over at less wrong[0]. The act of 'breaching' security is of course altering someone else's decision(to suit your needs) with false/fake inputs that your target fails to verify correctly

To be secure in the decisions you make you must verify all the inputs into your personal decision algorithm. For humans this system is more often right than for computers.

We have eyes: we can see who we're talking to, computers only have a vague 'trust' 'these numbers ensure that who you're talking to really is who he says he is'. A very fragile system that can be broken if enough resources are available to the adversary.

Now I'm not saying that the 'trust' systems of humans and computers differ fundamentally as both rely on external inspection (eg. I can't read you mind I'm still only basing my trust in you on what my senses tell me), but I do say that the 'trust' of computers has a much lower standard as opposed to that of a human.

We can better verify if what others are saying is true, in any context. Human understanding, under most circumstances, is such that it allows us to test things that others are saying on a huge amount of experience and knowledge, either that of our own or that of other humans.

Computers, on the other hand, only understand the protocols we've written for them. And those are only as good as the risk predictions of the programmer(s) that wrote the protocol. They are very limited and very fragile in the sense that they age and weaken as they get older. What if a break-through in prime-factorization is to take place at this very moment? In one swoop we'd lose a major part of the security infrastructure on the Internet. There is no reason to believe that prime-factorization can't be solved efficiently and quickly, someday. A human faced in this situation understands that his/her security protocol no longer suffices, he/she would change said protocol.

Of course, in the hypothetical scenario of prime-factorization break-through we'd just patch the systems, right? Yes, but then we're back at playing whack-a-mole again.

Last but not least, there are no huge/vast differences of intelligence between two people talking, where one is trying to manipulate the other. Sure Einstein vs the Village idiot could be considered a 'vast' difference in intelligence. But next to the differences in what constitutes intelligence for computers it is almost negligent. A smart phone with a punny dual-core processor must somehow be resistant against billion-dollar super computers, hell your simcard who's clock-speed can be measured in megahertz must be resistant against these super computers. It's just not doable, such a difference in capabilities just does not exist between two people.

Of course when you start mixing people and computers, your security is only as good as the weakest link (the computer). You would not fall for a 'phising' talk if you were face-to-face with the hacker (who is at this point not inside your network yet). The scenario is akin to the hacker, who's outside your door, asking you to give him the key. You wouldn't fall for this. But in your email program things are different, you can't see a face. Can't hear the inflections in the hacker's voice, he isn't even asking for the key he's only asking for you to click a link...

The solution, in a very general way, would be to design systems such that they are more 'intelligent'. Some sort of AI security. Don't just make the protocols more complex by adding more rules/functionality to it, instead program the computer in such a way that it can be 'inventive' in verifying it's inputs. Obviously such a system does not exist (yet?), and it's only wishful thinking that it can exist anytime soon (no infrastructure or backwards-compatibility), software not there yet, hardware might be but not sure). So for the time being we're stuck playing whack-a-mole.

[0] http://lesswrong.com/lw/v9/aiming_at_the_target/ - Aiming at the target.


I just want to point you out to a book. It is a good read, I promise.

http://www.amazon.com/Social-Engineering-The-Human-Hacking/d...

It looks like you genuinely believe that two people talking face to face would not be subjected to exploitation.

The book exactly talks about how exploitation in this context had been thriving even before Computer and Network Security became a thing.

In computer setting, an adversary still needs to do factorization to crack keys or priming the victim's computing machinery, both of which require advanced knowledge in science and technologies mind you, to do the exploits.

But for people, they come with beliefs, cultural and social biases, personal habits, and ignorance which are not too hard to discern, making human factor in systems a larger risk.


>We have eyes: we can see who we're talking to

And yet your security would still fail visual inspection if there was an evil twin brother.

>Of course when you start mixing people and computers, your security is only as good as the weakest link (the computer).

I disagree. It's almost always the human, except in cases where the human is very well trained in security.

Most of the problems you talk about have analogs in the real world, and existed long before computers were at thing. Set most people in front of a camera and tell them to look for shoplifters. Set a trained specialist (or thief) in front of the same camera and they will far more often see the theft occurring.


The point is that there is another possible outcome beyond the "yes"/"no" questions you asked, which is "I can't do my job with these security requirements" and "I don't understand these complicated methods and/or requirements". Both of these lead to security being bypassed on purpose, which is often far worse than the risk of someone walking in with a trojan USB stick.

Education about the risks involved in picking up random hardware, email requests/attachments, etc are important, but so is acclimating the average user to the very idea of secuirty. Both sides need time and experience to find ways to make security and the work being done compatible with each other.

A good example of the problem is PGP/GPG - it's too complicated and has a terrible UI (for most peole), so nobody even bothers. Yes, even if we somehow forced everybody to use GPG, the mistakes made while using it will likely compromise most of the "protected" data.

On the other hand, even if we went into the situation expecting 100% failure due to someone messing up, there would still be benefits. We would end up with keys being exchanged (infrastructure), making the beginnings of a trust network. Even better, we would see a lot more people starting to learn about keys and how they should (or shouldn't) be trusted.

TL;DR - never let perfection be the enemy of good, even in must-be-perfect security; even if it will probably fail in the usual sense, it may be worth it as a necessary lesson for future security attempts.


I have little practical experience with IT security, but I like to look at these issues from the side of the customer. There's a quote I like to repeat:

"If you prioritize security over accessibility, you'll have a perfectly secure system that noboody ever uses, ending up with zero customers. But if you prioritize accessibility over security, you can still build something as large as PlayStation Network."


Funny, it's the Infosec guys (me) with the coolest tools and some of the most innovative code where I work, but IT won't let us use FOSS monitoring software because it hasn't gone through the proper approval board.

See how broad that brush was?


That's why I put (most) in parens. While I'm generally disappointed with the majority of infosec, there are really good infosec people out there. In my experience the good people in infosec are really, really brilliant, and are also just as frustrated with the rest of the field.


Infosec is largely a ghetto populated by people who only think about one thing, and who think that one thing is the sexist, coolest, most important thing in the entire world. There are other such ghettoes and they all suffer from similar sorts of problems.

I normally avoid "me too" comments. But that's the most insightful comment I've seen this week for sure, and probably this month.


> Another notable one is C vs C++. Short version: I think C++ is fine and makes it a lot easier to do many things, but anyone writing C++ should have YAGNI and KISS tattooed on their forehead.

But that is the pain point. Most developers don't care to wear such tattoos.

Lint was created alongside C and left to a separate tool as per UNIX philosophy.

The result is that C and C++ developers never cared about it.

We had to wait for LLVM and daily security exploits for developers to start caring about it.

And now almost every C and C++ compilers offer static analysis.

This is why languages like Ada and SPARK are slowly being looked into by some European companies.

Intel is building pointer and buffer validation in their new processors as a means to help bringing safety to exiting applications:

https://software.intel.com/en-us/articles/introduction-to-in...

When security is not outsourced to a separate tool, it cannot be avoided.


I wholeheartedly agree with your commentary about such "compartmentalized" approach to systems tasks. The description of narrowmindedness is on target for many domains, certainly I've observed it in medical fields.

The problem arises from complexity. We are able to track only so much information at a given time so specialization develops. But as we find out more and more how processes intertwine it calls for having awareness of the generalist point of view as well.

It's a difficult feat to accomplish, to hold a meta and detailed view simultaneously. Probably it's a particular talent to be able to do so, but as complexity is not going to decrease, future leaders will need to be talented in this way if the problem is going to be solved.


To some extent I blame the Silicon Valley cult of recent grads, where "25 is the new 55" as someone once put it to me.

One of the things you get from doing something for decades is a very broad and deep understanding of the entire system. If you've been a developer for 35 years you've not only seen fads come and go, but you've also had a chance to use numerous systems from numerous perspectives and on both sides of the user/developer fence.

It only works if you've kept learning though. I've found that older devs occupy an extreme "U" distribution -- they're either utterly outdated or they're super-brilliant and can leverage tons of experience.

Another source of the problem is a lack of emphasis on -- or even contempt for -- UX among systems level (so-called "neckbeard") type developers. "Real men don't need ..."

Last but not least you've got the business models of many infosec companies which revolve around "streaming" constant "definition updates," patches, and selling loads of different one-off fixes for little problems.


I don't think it is a contempt at the existence of UX. But when UX gets in the way of efficiency. Something like being able to wrap up a common task in a script, rather than having to constantly poke at that wizard with its 1001 next buttons.


The vast majority of infosec gives zero thought to any concern other than security, resulting in systems that are insanely complex with incredibly poor user experience.

At Ruxcon last year, one of the speakers mentioned that security 'recommendations' from infosec come so thick, fast, and complex, that not even security specialists (who are up-to-date and fully aware of all the issues) use them all. He then gave a few examples of security specialists ignoring their own recommendations because it was 'too hard to comply'.


I would suggest having YAGNI and KISS tattooed on your knuckles instead, where you'll actually see them. Unless you have a little mirror on your desk. In that case, go ahead with the forehead tattoo. (Make sure they do it backwards.)


That old term comes to mind, "perfect is the enemy of good".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: