Apr 2, 2009

Help Thomas succeed

This morning, Thomas and I were discussing how somethings can take longer than usual in our organization, like design and security reviews.

We could continue as-is but what's the fun in that...

So, I challenged him to finish his project's security review in one session. Doing this in only one session will earn him EE (exceeds expectations) on this effort.

What should Thomas think about? What's your advice for him?


  1. Think about the data really hard. Understand the current data requirements and think about the potential requirements thoroughly for that release. Once you've done this thinking, you're ready to have your discussion with Security.

  2. This comment has been removed by a blog administrator.

  3. I had a few security reviews which went smooth. What I have learnt from these reviews:

    We need to make sure that security team understands that we(development teams) do care about developing secure applications. I think a good preparation for the security review will demonstrate that. I am not saying that development teams should create documents not knowing whether they will be used, but at least be prepared with the minimum info/documents. I am sure you will have all the architecture related documents, project vision , etc.

    In addition:
    - Create a roles and privileges matrix(RPM): Roles and access rights, no.of potential users for each role, approval process to gain access, role of the user in the organization(back office/executive), etc. I have a framework for RPM which some of us have used on projects and found beneficial, and it would really take very less time to put this together. In additional, this documents will make it easier to review the functional security requirements with your sponsors, and make you answer some the questions which you have to answer down the line on your projects. For example: no of potential users per role. You would need to know that for load/performance testing or setting up infrastructure.

    - With respect data in your application: at least be prepared with the list of objects/tables in your application, and may be expand to the details i.e, field level for what you think is sensitive (say for ex: customer data, personal info, evaluations, compensation, etc). If they need details of something you did not expand they will ask you anyway. Sometimes, I find it easy to give them the entire list of objects and attributes exposed to end users, and only object level for system objects (for example: audit tables)

    There are other things they may ask depending on the type project such as password maintenance and recovery, confidentiality & integrity , auditing & compliance, system availability, penetration testing, etc

    At least this is a good beginning !!!!

  4. This comment has been removed by a blog administrator.