What kind of network do you have at home?What you don’t want to hear is, I get enough computers when I’m at work.. I’ve yet to meet a serious security guy who doesn’t have a considerable home network.
Ehrm... sorry. At various times in my past I've had: a garage with two server racks, several BBS systems, a coffee table made out of a small beowulf cluster of recycled SUN sytems, various media servers, a PBX system, most switches/appliances rigged up to X10, a cross city wireless link on my rooftop, remote-login-via-packet-radio, various centralized login systems, etc, etc....
But now I have: a router, MacBook Pro, Vonage box, and a big USB HDD for backups. Sometimes I plug in a projector to watch movies.
I'm not "just looking for a paycheck", but that doesn't mean that I have to maintain a second enterprise network at home to stay sharp. Certianly not now in the days of vmware and cloud computing.
Employers seriously need to grasp that a work/life balance is the sign of a healthy, professional employee with his/her act together...
These questions make security professionals sound pretty dumb. I'd look for someone who understands systems deeper than the people who build on them.
Here on HN, we look for credibility in terms of projects and businesses launched. The security world looks for community contributions and research.
These questions are too much like a vocabulary exam with extremely low expectations. If all you're looking for is someone who breathes and can tell the difference between HTTP and HTML--you're missing a lot that a real security professional can bring to the table.
[P.S. I reread the questions and now I know why this article bothers me--they sound like regurgitated certification questions. Monkies get certifications, hackers do stuff. Ask these questions when you want to hire a monkey. If you want someone who breathes security, hold them to the same standards you'd hold a developer to--ask them to show you something they've worked on.]
I think some of the questions obviously vary in applicability dependent upon the role being interviewed but in general most of the questions I would say form a good set of base questions to sort the wheat from the chaff.
Going through them I see that I got a few wrong, most notably with elements of crypto, so it's helpful in terms of me understanding the areas I'd need to improve, which for me would be the best thing I could take away from an interview where I'm not offered the job I want.
"Cryptographically speaking, what is the main method of building a shared secret over a public medium?"
I overlooked diffie-hellman, expecting something more complex and goofed out. My answer was "I wouldn't use a public medium, I'd go out of band to share the secret".
Having said that, I understand that crypto is not my area, and that I need to improve, which gives me some good pointers moving forward. Theoretical crypto isn't my thing (infrastructure, malware reversing and other bits of app sec are my thing for want of a better term - as far as crypto goes there are other people in the team that do a better job than me and I accept I'm lazy in this respect so it's a good pointer for me to improve).
Don't worry, it's common to get poorly worded questions wrong when you don't understand what exactly the examiner is asking. In this case, I too would have gotten wrong unless you replaced "building" with "exchanging".
A little vocabulary heavy, but mostly good. Be careful not to reject someone just because they use the word "threat" for a different concept than you do (but can reason fine about both concepts).
And role-playing should be seen as mandatory. It shows if the candidate can apply their knowledge. This is vital, and not everyone can.
That's ok. If you have that little patience with foolishness, I don't want you running my security. Users' foolishness gets a lot worse than that, and is most organizations' biggest vulnerability. Sometimes you just lock down their workstations, but sometimes that isn't an option. Then you have to face the problem directly. Getting up and leaving won't help.
Excellent questions, and a good discussion of the range of expected answers. I particularly like the discusison of "Are open-source projects more or less secure than proprietary ones?":
My main goal here is to get them to show me pros and cons for each. If I just get the “many eyes” regurgitation then I’ll know he’s read Slashdot and not much else. And if I just get the “people in China can put anything in the kernel” routine then I’ll know he’s not so good at looking at the complete picture.
I don't understand something about infosec interviews (and that goes for the CISSP as well).
Why bother asking about crypto at all?
* What’s the difference between symmetric and public-key cryptography
* In public-key cryptography you have a public and a private key, and you often perform both encryption and signing functions. Which key is used for which function?
* Cryptographically speaking, what is the main method of building a shared secret over a public medium?
* What’s the difference between Diffie-Hellman and RSA?
* What kind of attack is a standard Diffie-Hellman exchange vulnerable to?
* What’s the difference between encoding, encryption, and hashing?
Here's my issue: if these are the questions you're asking, you're clearly never going to actually work with cryptography in your job. You may indeed end up deploying some appliance that uses "standard Diffie Hellman" somewhere, but you'll have no more control over that than you would over the LZW variant it uses to compress.
And that's fine! I think fewer people should deal with crypto, because people invariably get it wrong. But it's my suspicion that these questions are really just shibboleths; they're trivia meant to establish whether you're in the club or not.
In contrast:
* Where do you get your security news from: you will somehow have to keep abreast of security news (although, be honest, this is really just a question designed to bolster the club of security bloggers).
* What’s the difference between HTTP and HTML? Presumably if your candidate doesn't know how computers work, they won't do well at infosec.
* How does HTTP handle state? This is a fine question, although I don't understand why he calls cookies a "non-native" hack, since they're standardized as "HTTP's State Tracking Mechanism".
* What exactly is Cross Site Scripting? Sure, this is a great example of the kind of vulnerabilities corp infosec people routinely stumble across...
* What’s the difference between stored and reflected XSS? ... and if you've read anything about XSS, you know the OWASP-y taxonomy (although I might ask a corp infosec person to recite the OWASP top 10 instead)...
* What are the common defenses against XSS? ... and sure, you should know how to spot a bad fix to XSS, like trying to filter the <script> tag.
* What kind of network do you have at home? I have a Macbook. And an access point. I think the access point might be a 2wire? I guess I'm out the door.
* What is Cross-Site Request Forgery? As with XSS, a reasonable appsec thing for infosec generalists to know.
* How does one defend against CSRF? A little less reasonable but still germane (he appears to get this one wrong).
* What port does ping work over? This is the oldest trick question in the book (I think Cambridge Technology Partners made it up), but, sure, you're going to have to be able to firewall ICMP in your job.
* How exactly does traceroute/tracert work at the protocol level? One of my favorite interview question for developers is "how would you speed up normal traceroute" so I'm biased.
These are all reasonable questions, some I like better than others, that all have something to do with the actual job of being in infosec.
I completely disagree. A person who is really passionate about IT security will know about cryptography because they are interested in how security works, not because it's a requirement for the job interview. In fact, I am surprised at the number of highly paid security 'professionals' who are little more than auditors with a pen and a form to tick.
Asking about crypto is a great way to weed out the auditors from the pros. There is also a difference between cryptographic algorithms and cryptographic implementations. I wouldn't expect you to write algorithms, but I definitely would like you to explain real-life implementations. A good set of crypto questions to ask, that are quite basic and yet will trip up lots of security pros:
* What's the difference between a Verisign certificate and a self-signed certificate?
* In which environment would I use the Verisign cert and in which one would I use a self-signed?
* In what cases would I expect the Verisign cert to generate warnings in my browser? What about the self-signed? How do I fix these errors?
Questions about Verisign certs vs. self-signed certs are good, because that's an issue that actually comes up in infosec.
There definitely are good crypto questions to ask. But these questions aren't those. They demonstrate only enough of a command of cryptography to pass an interview. They're signalling questions, not assessment questions.
And, with the exception of things like "what's wrong with self-signed certificates", the real crypto questions will weed out essentially 100% of your candidates (and 99% of appsec candidates as well). Note: the "real" questions I'm thinking of have very little to do with algorithms.
There's a word for things you ask about because a person who was really a member of your club would be fascinated by them: shibboleth.
Some more interesting crypto questions, for interested HN'ers:
- Write code to verify message integrity, given a tuple (message, authentication_code) and a function authentication_code(message) (Google "Timing attack" if you think you couldn't possibly get this wrong);
- We store passwords salted and hashed with MD5. What do you think? How about SHA1? (Yes, this is bad, since these algorithms are too fast and hence allow dictionary attacks on the passwords; "PBKDF2" or "OpenBSD's Blowfish scheme" are good; bonus points if they know about scrypt; should include a discussion of password complexity);
- An open source project put a project-1.0.zip, project-1.0.zip.md5 and a project-1.0.zip.md5.sig file on their FTP server. Discuss. How about SHA1? (The .md5.sig file safeguards the .md5 file, provided the PGP key used is well-known. Collision attacks for MD5 exist; therefore, a malicious maintainer could serve a carefully-chosen but benign file to most clients and one with a backdoor to, say, .mil. Conversely, no (second) preimage attacks are known, so only the maintainer could do this. SHA1 is safe, for now, but it would be wise to upgrade. Bonus points if they know that the zip format is easy to manipulate. A small amount of bonus points if they express surprise at seeing a zip, since it's mostly GNU projects that use this "double checksum" and those tend to use tarballs);
- We have an API of the form http://mysite/set/key1=val1,key2=val2,...,keyN=valN,hash=foo where foo=MD5(customer's secret || key1 || val1 || key2 || val2 || ... || keyN || valN), where || denotes concatenation. Discuss. How about SHA1? If you disagree with this design, what would you propose? (This idea, based on an old design of AWS, is completely horrible, for either MD5 or SHA1. The obvious issue is that MD5(secret || "a" || "b" || "c" || "d") = MD5(secret || "ab" || "cd"), so that it's a valid hash for either a=b,c=d or ab=cd; the less obvious issue is that MD5 and SHA1, being based on the Merkle–Damgård construction, allow calculation of MD5(msg || msg2) from MD5(msg) and the length of msg. The correct solution is to use e.g. HMAC-SHA1(customer's secret, key1 || "," || val1 || "," || key2 || "," || val2 || "," || ... || keyN || "," || valN), ideally with a way to select the algorithm. Or use HTTPS with client certificates.)
But I agree that people, by and large, shouldn't be directly using any of this stuff.
Not only are these just trying establish if you're in the club or not, but judging from his answers on the DH vs RSA questions (which are not-well formed to begin with), it seems like he's trying to establish if you're in the club that knows the names but has no knowledge of WTF is actually going on in crypto.
I'm the author and I wouldn't say I am a crypto guy, but the conceptual difference between RSA and DH is clear to me, and I defend the proposition that it should be for others in infosec as well.
I can't speak for the parent comment, but saying that "Diffie-Hellman" is a good answer to the problem of establishing a secure channel over an untrusted medium is like saying "plutonium" is a good answer to the problem of submarine propulsion.
It's a category error to those well-versed in cryptography, like "explain the difference between mergesort and recursion" - two unrelated concepts. (Whereas "explain the difference between quicksort and mergesort" is an interesting question.)
Your answer also does not sufficiently differentiate between e.g. key agreement (DH), message authentication ("signing"; HMAC), symmetric encryption (AES), or asymmetric encryption and signing (RSA).
I completely disagree as well. A security professional will often be in charge of evaluating various vendors encryption products for potential use within a company. If they know nothing about key management, for example, how would they even know how to evaluate the security (or lack thereof) of any given encryption solution?
This is exactly the thing I am saying "give me a break" about! Knowing what public key is, or that DH can be "man in the middled" is not enough to assess vendor crypto. It's not even close. More importantly, knowing the answers to these questions isn't even an indicator that you might know enough to assess vendor crypto.
And that's fine. Very few people (even in appsec) have that qualification. By way of example: I don't consider myself one of those people; I know three of them, total. Colin Percival might not consider himself one of those people.
What's not fine is pretending you've assessed a qualification that you don't understand.
Most of the infosec people I work with would score exceptionally low on the questions in TFA. That's because to do their job they have to argue with management, get buy in etc. Unless there's a gaping hole they're going to go with whatever the product does. They're not going to get involved with key exchange algorithms because the tool abstracts that. They're going to get involved with compliance. That's why we have things like FIPS-140-2, Common Criteria, EAL, CAPS etc.
Is that a bad thing? Possibly. One would hope that such products do a proper job. The realisation is not always so. We've broken two FIPS-140-2 products in the past 3 years, one of which was used in the Chinese olympics bid with dangerous results.
Personally I think knowing your boundaries and being able to express them (for example whenever people mention crypto I tell them I'm not the right guy, and if it was transatlantic I'd definitely say tptacek would be someone more worth talking to in that area) is more important than attempting to be a one-stop shop for all things security.
In question 1.3, if you send merged packets of the form <pkt1,pkt2,...,pktN,sign(key, (pkt1,pkt2,...pktN))> where "," denotes a suitable delimiter, I don't see any new DoS opportunities. Does anyone see them?
(I think the person who wrote that question wants you to send separate packets pkt1, ..., pktN and then a signature over all these packets; in this case, an attacker could disrupt the protocol by inserting a junk packet, causing the verification to fail.)
Those questions and this thread blew me away: I'm way behind on both of them.
Yes some years ago for maybe a few hours I understood Kerberos and RSA and using RSA to 'sign' a document. And once for about an hour I understood the keys, handshaking, etc. of Microsoft domain servers, Active Directory, or whatever. But I've never since had any occasion to revisit those ideas or any deeper ideas.
Gee, when I took abstract algebra, I got enough number theory to understand and prove Fermat's little theorem, etc., but I've never had to use it. Maybe if I take some of the old source code I have for PGP and want to revise it, then I would look at such number theory again, but I likely shouldn't be working with the internals of something like PGP.
Gee, once I read
David J. Marchette, 'Computer Intrusion Detection: A Statistical Viewpoint', ISBN 0-387-95281-0, Springer-Verlag, New York, 2001.
and understood that well enough, but I'm still nearly clueless about that article and this thread.
Maybe I should know more: I'm building a Web site that I hope will be popular. So I'll have to run a 'server farm' of the necessary size and manage the network in the farm and the connection to the Internet. So, again, maybe I should know more.
Maybe some of you guys could post some more on this thread and get me, and people with similar ignorance, partly caught up.
So, my first broad question would be, in considering my computer and network security, will I really have to work at the relatively low level of those question? E.g., I know next to nothing about SSH, but I will make use of it via software from others. Do I really need to understand SSH at the level of the packets, handshaking, keys, etc.? If I was curious, would thirty minutes with some Wikipedia article be enough? Would I be able to get enough low level access even to use such details? Is it enough and about all I can do just to leave the details and implementation of SSH to others? E.g., I just spent 12 hours today reading about SQL Server logins, users, Windows authentication, permissions, roles, schemata, etc., but again I just get to use these things as a part-time DBA and don't get to see or work with the details. Similarly for other important parts of network security?
Second, is it really true that commonly information security professionals in US companies need to know and work with such details? E.g., when the world changes over to IPv6, will I have to know the details or will I just leave the details to the people who write the code and build the hardware?
I can understand that Cisco, Juniper, Microsoft, developers of Linux, and intrusion prevention device designers need to understand Ethernet and TCP/IP at all levels, but do I?
Net, how much detail is needed, and what is it actually used for?
Ehrm... sorry. At various times in my past I've had: a garage with two server racks, several BBS systems, a coffee table made out of a small beowulf cluster of recycled SUN sytems, various media servers, a PBX system, most switches/appliances rigged up to X10, a cross city wireless link on my rooftop, remote-login-via-packet-radio, various centralized login systems, etc, etc....
But now I have: a router, MacBook Pro, Vonage box, and a big USB HDD for backups. Sometimes I plug in a projector to watch movies.
I'm not "just looking for a paycheck", but that doesn't mean that I have to maintain a second enterprise network at home to stay sharp. Certianly not now in the days of vmware and cloud computing.
Employers seriously need to grasp that a work/life balance is the sign of a healthy, professional employee with his/her act together...