Seriously, don't ask trick questions in interviews. You put the candidate in the impossible position of having to correct the interviewer, and the reaction to that tells you absolutely nothing about what the candidate knows or will do in a real-world situation.
"at least access to one, even if it's not at home."
And yet, this candidate will often simply answer "None" because you didn't ask about access to a network, even if the candidate maintains multiple complex networks at family members' homes.
"Are open-source projects more or less secure than proprietary ones?"
Don't ask yes/no questions if what you really want are pros and cons. Ask for pros and cons instead. Interviewing shouldn't involve mindreading. A lot of people will respond to a question like this by stating a thesis and then defending that thesis.
A lot of your questions have that problem. You're asking specific things, hoping that the interviewee will catch on and give you general answers. That seems to be testing interview skills more than anything else.
These are not IS questions, they are ITS questions. There is a very serious difference between the two.
ITS without IS governance, policy, and management is worthless. It is chasing ménaces du jour, not actually managing security.
Were I interviewing someone for a serious and senior IS role, I would start with social questions, asking them to describe what organizations they consider to be the most threatening in general and to businesses in my country and field specifically, and why.
I would describe (hypothetically, without saying so) an organization like mine (but different enough to give away little), its flaws and concerns, and ask them how they would address those flaws.
Were I to hire that senior IS person, I would let them build an IS organization, which would include an ITS component.
Without policy, governance, and management, you do not have security, you have techno farce - and your organization will remain perpetually reactive, never really knowing how secure it is, never really being able to assess risk reasonably.
"How would you implement a secure login field on a high traffic website where performance is a consideration?"
....
"wanting to serve the front page in HTTP, while needing to present the login form via HTTPs"
Maybe. There will still be a link on the HTTP page that takes you to a HTTPS page with a login form. Someone with MITM access could alter that link. A better way would be to serve all pages via HTTPS
Is it really true that you should compress before you encrypt? IT seems to me that the encrypted message should have the same amount of "information entropy" as the original message, so it should compress equally well.
Definitely compress first. While it is true that there is the same amount of entropy before and after encryption, you'll never be able to identify it from the bitstream (otherwise your encryption is broken). Compression works by understanding statistical patterns in the process that is creating the data stream, and encoding the data based on this information to achieve a reduced stream size. An encrypted stream is generally assumed to be indistinguishable from random data, so you won't get nearly as much (if any) compression from this pseudorandom stream.
I always thought it was good to compress first because you can more easily avoid frequency attacks. In that way I think it's better to compress then encrypt.
EDIT: That and you get to encrypt a shorter data stream. I realize frequency attacks aren't as much of a concern these days but it's just the first thing that came to my mind.
Also, some encryption systems integrate compression; like OpenPGP -- it supports ZIP, ZLIB, and BZIP2. So in such case, it may well be just sufficient to encrypt uncompressed data.
This stuff is basically at the CISSP CBK level, i.e. essentially worthless except as screening questions. Maybe it's ok as a baseline, but you really want something deeper and more relevant to your specific position.
I thought the same thing when I read that. When I was thinking of "integrity" from a security perspective (as you might in an article like this) it didn't make sense. But when I thought of it more from a pure data transfer perspective between say a browser and the application it made more sense. I don't think he's saying that it's safe from mitm attacks. (At least, I hope not....)
Think of integrity as fidelity. Encoding ensures that your information can be reconstructed accurately on the other end of a communications channel (whether that be the internet, to and from the hard drive, or even just to the person standing next to you).
"What port does ping work over?"
Seriously, don't ask trick questions in interviews. You put the candidate in the impossible position of having to correct the interviewer, and the reaction to that tells you absolutely nothing about what the candidate knows or will do in a real-world situation.
"at least access to one, even if it's not at home."
And yet, this candidate will often simply answer "None" because you didn't ask about access to a network, even if the candidate maintains multiple complex networks at family members' homes.
"Are open-source projects more or less secure than proprietary ones?"
Don't ask yes/no questions if what you really want are pros and cons. Ask for pros and cons instead. Interviewing shouldn't involve mindreading. A lot of people will respond to a question like this by stating a thesis and then defending that thesis.
A lot of your questions have that problem. You're asking specific things, hoping that the interviewee will catch on and give you general answers. That seems to be testing interview skills more than anything else.