This is probably part 1 of an ongoing series, highlighting some of the key phrases I hear when talking to candidates for security positions. Many of them are also “accepted truths” out on the Internet, and so it’s an opportunity for me to prevent some memes from distributing.
There’s no security advantage between TCP and UDP
Because, clearly, there is. UDP, like ICMP, IP, etc, is frequently forged in order to trigger echo attacks and the like. TCP, by comparison, uses randomised Initial Sequence Numbers (ISN), and while this isn’t enough to allow you to use IP addresses on TCP connections as an authentication mechanism, it’s better than the nothing that you get with UDP.
Closer to the truth: The security advantage TCP has over UDP is minor.
OS <name> is more secure than OS <name>
Each OS is most secure when it is administered by a competent and knowledgeable technician. Me administering a Linux system would be less secure than me administering a Windows system. One of my more Linux-based colleagues, on the other hand, will find that their Linux system is more secure than their Windows system.
Frankly, you don’t buy an operating system for its security, you buy it because it runs the apps you want to buy or want to develop.
Closer to the truth: Some operating systems make it easier to protect against some classes of threats than others.
The firewall protects it
The correct name for the device commonly known as a “firewall” is a “hole wall”. OK, so I’m joshing a little there, but while a firewall will prevent many errant connections, that’s only going to help if you don’t have open ports for vulnerable services – and you wouldn’t be putting the system on the network if it didn’t need to be reachable at some point, through a hole (or holes) punched in the firewall.
Web application firewalls (WAFs), IDS, IPS etc have similar purposes – keeping out the bad stuff, and letting in the good stuff, but then you have to spend a lot of time defining what’s good and what’s bad. Then you have to hope that the “good” you let in doesn’t also encompass some “bad” to which you are vulnerable.
Again, firewalls provide value, but they’re not the complete protection many assume.
Closer to the truth: The firewall protects the device from having to handle and reject traffic the device does not intend to receive. This leaves the device freer to protect itself from traffic on its intended port.
I studied this on YouTube / Google / FaceBook / the web
YouTube is the home of many a poor video on security topics, including the (unintentionally) hilarious NextGenHacker101 teaching us how to use “tracert” to count the users on Google. Similarly, while there are many good sources of information on the web, there’s also a lot of really bad information, and some of it is not so obviously bad as my YouTube example.
Even this blog, a paragon of fine security advice, occasionally treads into the sarcastic and ironic, or just plain aims to deliver pithy ‘sound-bite’ length advice, which may not completely satisfy the subtleties of imparting good knowledge.
You can’t beat a good book, technical article, training class, or other ‘official’ source, when it is combined by experience, experimentation and exasperation. The three Xs, if you will.
Closer to the truth: I use Twitter / Bing / Blogs to catch up on what my favourite security researchers are doing today, and then I go and research what I read elsewhere to make sure that I’m not responding to tat.
I learned everything I needed to know in my <name> certification study class
No you didn’t, you learned how to pass the certification. At least, that’s what I’ve learned from certification classes – including some extremely sketchy security information and downright outdated and historical technologies that I would be embarrassed to suggest using in a real life environment.
I won’t say it wasn’t useful studying some of that material – I certainly learned a few new tricks from cert classes, although I also learned that a great many people have certifications that are not indicative of anything more than their desire to spend several hours dumping information into their heads, and another hour or two dumping it back out. Much like pouring milk into a jug and then out again, there are some vessels that remain surprisingly clean after the fact.
Closer to the truth: I train to improve my knowledge without having to slowly gain experience through my own mistakes. I get certified because it impresses some people (HR, other teams, etc), and sometimes that’s a necessary first step..
Security is all about being paranoid
No it’s not – security is about knowing and accepting, transferring or mitigating the risks to those assets you and your business deem to be valuable. That will include monetary equivalents (such as credit cards or gift cards), reliability / availability, privacy, and such intangible items as trust. Being overly paranoid prevents many businesses from actually achieving some of their business goals, and can cost more than it saves.
Closer to the truth: The ability to act paranoid can help greatly when enumerating threats. But not every threat is realisable, and not every threat can be protected against at a reasonable cost. A paranoid mindset will not see or accept that.
You have to think like an attacker
Not really – though this is something worth telling developers who haven’t thought about security, if only to make them think of a new paradigm. But then you have to move them through this mode. [Many developers still do not understand that their application may be the target of an attack]
What you have to do is think like a defender, because attacker and defender have very different goals.
While an attacker is looking for a single instance of a flaw or vulnerability, a defender’s time is best spent looking for, and addressing, whole classes of vulnerabilities at a time.
A QA / Tester might find benefit in thinking like an attacker, but they are usually already pretty comfortable with the idea of trying to anticipate what the developers didn’t think of.
Closer to the truth: There are people out there, thinking like an attacker, and ready to attack your code. You have to figure out how to defend against that.