Partager via

Security Architecture

  • Article

One of the disadvantages about being the oldest in the group, apart from receding hair and growing stomach, is that I tend to get asked to do the technical part of the new candidate interviews. When we are doing lots of interviews as we are at the moment this can get a bit samey. In this present round I have had my boss sitting in and I think he is getting bored too; in fact he has taken to asking me to “throw in a scenario” or “do something different”.

The other snag is that I get to interview on topics I know very little about (a wide field!). Today I had to do an interview for a security position; something I know next to nothing about. Given my lack of knowledge I decided in the best architectural fashion to split security into areas and then build a scenario starting at the bottom and working up.

It appears to me that there are 4 main areas in security:

1. On the Wire and keys (public, private, asymmetric, DES, RSA, Fractal, QKD)

2. Authentication/ Authorisation Sub Systems (Gina, LSSA, SSPI) (Kerberos / PKI, trust and federation) WS-sec,

3. Single Sign on / heterogeneous systems, agents, Directories / Identity and MIIS

4. Application LDAP, ADSI

So after a few warm up questions on the advantage and disadvantages of fractal keys and what changes would be needed to Windows to add in non standard password encryption I kicked off with a banking scenario.

This was set around a very large bank which had a Mergers and Acquisitions strategy and had standardised on Kerberos but wanted to have a single user id and password across all its acquisitions. This led into Kerberos scalability and manageability and thence into PKI and discussions of the differences between trust and federation.

Next in the scenario the bank wanted to standardise around a SOA for applications which led to discussions around support for trust and federation in WS-Security.

Then in the scenario the bank wanted to provide single sign on across W2k, UNIX (LDAP) and Mainframe (RACF) systems which covered off agents and password update and synchronisation with a quick dip into directories and Host Integration Sever (one of my favourite products).

Finally the bank had employee data on CICS which it wanted to use to validate access to the HR application running on the UNIX system. This led into Identity Services and MIIS discussions with a quick look at AD extensibility and ADSI and ADO AD access

 

It was a fun scenario which my Boss enjoyed; I’m less sure about the candidate’s feelings. His comment was “That’s the first time I have looked at security in this way, it was very interesting and I learnt a lot”. Actually most people say they learn a lot in my interviews, I am not sure if that is a good or a bad thing!

Comments

  • Anonymous
    July 14, 2004
    Please take this as a good thing. As I have done many a technical interview in my day (it is sometimes exclusively what I am hired on to do!) I can attest to the difficulty of finding and asking the right questions in the interview. If the interviewee says that they have learned something this is usually an indicator that some rapport has been established.

    Depending on how my client wants me to interview I do not nessearily rely on the interviewee getting all technical answers correct. However, the manner in which they approach the problem is the key indicator of a good employee in my book. Technical prowess can be learned, an inituative way of looking at a problem however takes far more time and quite frankly more intelligence.

    Thanks for the good ideas on performing technical interview. I learned something from this post <g>.
  • Anonymous
    July 14, 2004
    The comment has been removed
  • Anonymous
    July 14, 2004
    If a security guy can't talk to a business unit manager, end-user, infrastructure engineer and also understand the cryptic mind of the application architect is in trouble anyway. [wink]
  • Anonymous
    July 15, 2004
    That must be it. :)
  • Anonymous
    July 16, 2004
    The comment has been removed