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.
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?
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 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?
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?
[+] [-] furyg3|15 years ago|reply
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...
[+] [-] raffi|15 years ago|reply
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.]
[+] [-] _b8r0|15 years ago|reply
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.
[+] [-] tptacek|15 years ago|reply
[+] [-] dspeyer|15 years ago|reply
And role-playing should be seen as mandatory. It shows if the candidate can apply their knowledge. This is vital, and not everyone can.
[+] [-] 16s|15 years ago|reply
[+] [-] dspeyer|15 years ago|reply
[+] [-] tptacek|15 years ago|reply
[+] [-] desigooner|15 years ago|reply
[+] [-] jdp23|15 years ago|reply
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.
[+] [-] autarch|15 years ago|reply
[+] [-] tptacek|15 years ago|reply
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.
[+] [-] LabSlice|15 years ago|reply
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?
[+] [-] JoachimSchipper|15 years ago|reply
- 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.
[+] [-] cdavidcash|15 years ago|reply
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.
[+] [-] illumin8|15 years ago|reply
[+] [-] kunjaan|15 years ago|reply
http://www.ccs.neu.edu/home/noubir/Courses/CS6740/F10/proble...
[+] [-] JoachimSchipper|15 years ago|reply
(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.)
[+] [-] wyclif|15 years ago|reply
[+] [-] HilbertSpace|15 years ago|reply
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?
[+] [-] ryantk|15 years ago|reply