Skip to content

Ramblings of another geek

Geeky, by any definition.

Menu
  • About me – geeklog
  • Privacy Policy
  • Short Stories
    • The fury, and joy, of nature
    • Finding Freedom Within (2 very short stories)
    • The return of innocence
  • 🎓 The Scholar’s Compass: Guiding Graduate Research and Thesis Writing
    • Writing a Literature Review
    • 📘 Chapter-by-Chapter Application Design Report Guide
      • Chapter 1: Introduction – Instructional Guide
        • Chapter 1: Introduction – Fillable Template
      • Chapter 2: Literature and Technology Review – Instructional Guide
      • Chapter 3: Requirements and Design – Instructional Guide
      • Chapter 4: Implementation – Instructional Guide
      • Chapter 5: Testing and Evaluation – Instructional Guide
      • Chapter 6: Conclusion and Future Work – Instructional Guide
    • 📘 Chapter-by-Chapter Thesis Guide for Theoretical Research
    • 📘 Designing Innovation: A Graduate Student’s Guide to Writing an Application Design Report
Menu

Project management in the security space – trials and travails

Posted on August 24, 2007September 30, 2010 by mani

Today’s information security project manager faces the same dilemma that many engineers have learned to deal with over the decades – how to deal with incomplete information. Rigid time-lines do not allow for much flexibility when the information sought to complete designs or implement solutions is not available. Given the management concerns and compliance reluctance on release of ANY information even barely classifiable as sensitive, this happens more often than one is wont to believe. So how do project managers deal with this?

Some project managers I have worked with in the past have used the universal favorite – the segments of the project that could be held up by the delayed information are somehow contrived to be ‘out-of-scope’ – and the rest of the project is repainted as the complete project, and delivered ‘on-time’ and as an added bonus, ‘under-budget’ since the removal of the difficult items did not extend to corresponding budget corrections 🙂

Other project managers have made a fine art of this principle, using it fairly indiscriminately to always deliver projects on time and under budget or on budget. But this still leaves the base question unanswered – how do we deal handle getting the information in time? What are the project manager’s responsibilities and practical options for dealing with the solution?

Here are some tools that I have found useful.

1. Education – Project managers need to comprehensively understand information security and information assurance, at least to the extent we understand the fields today, before they are asked to manage IA and IS projects. These projects have the capability to negatively affect both public image and the bottom line if not carefully herded through to completion with due diligence. While the project management skills requirements remain the same, these project managers additionally need to understand not just the politics in an organization but also the information security and assurance drivers within the organization, and their interaction with all connected external clients and partners, and the way the client and partner relations drive the information security and assurance processes.
2. Due diligence – This is true for any project – do all necessary AND apparently unnecessary investigation and research up front to avoid unpleasant surprises later. Investigate the relevance of all required data, and clear the same with legal, compliance and risk teams well in advance. If new data paths are being created or old ones removed, do the same check with the above teams – and repeat in case the one member not present in the original meetings has a difference of opinion. If anyone complains about redundant questions or questioning, repeat the question again – and then again, for good measure. One person’s displeasure is fair play versus possible senior management unhappiness due to project delays and expanding budgets.
3. Measure risk – and report as widely as possible. Redo risk measures for all relevant systems, and all ancillary systems that could get touched. Develop a process to automatically (hopefully !) update risk measures of individual components as other components get added or deleted, or the metrics for a specific component change.
4. Work closely with risk management, help desk and computer security incident response teams – involve them from the get go to ensure that any incidents as the project progresses keep the project team in the information loop for necessary course corrections – instead of the ‘end-of-project-review’ when the security teams reject the entire suggestion!
5. Inform the architecture team (create one if the organization does not already have one) and ensure that there is a two-way flow of information regarding changes in the infrastructure and architecture landscape progresses: think of the number of projects that lost steam when someone realized that their work was no longer needed due to other design or business need changes.
6. Ensure business representation and participation – the project exists because the business felt the need for it, after all. No IT work exists in a vacuum – it is driven by business need and not vice versa.
7. The Information Security project manager needs SPECIAL people management skills. If you thought that IT professionals were a weird bunch, wait till you meet your first IT security tech. Then multiply that by 7 (the average team size ?!) and consider the fact that you will be closeted with them in conference rooms feeding them brain food (pizza and coke) for extended periods of time, at the same time having lost all contact with the real world. Think of spending sixteen hours at a stretch between fun terms like 10Base-T, Fuzzy logic randomizer, BMUS, CIA Triad , AES/DES/3DES, and YMMV interspersed by an extremely animated discussion (politic name for heated argument) on the relative merits of a layer two firewall versus a layer three firewall, or a unified threat management appliance versus discrete specialized components for each desired function, and their combined throughput merits.
8. Recognize excuses – and deal with them appropriately. Information security personnel are no different from the rest of the world – they succumb to pressure. Recognize the symptoms, and deal with it. However, realize that this crew is not really easily replaceable, and their inherent institutional knowledge is definitely not only replaceable, but takes a long time to reacquire for a replacement.
9. Pay attention to the undertone murmurings. In this environment, they could indicate potential show-stoppers, and make or break the project. Typically, most project failures can be blamed on poor management rather than technical ineptitude, but information security projects can fail for a new reason – changes in the information security landscape. Keep an ear to the ground, and follow the regulatory world with extra attention.
10. Love the job – Very important. If you do not enjoy this work, stay away – it can make a lot of people sleep a lot easier, including yourself! These projects can add feathers, but can also bring on the tar!

Got comments? Email me at mani SHIFT-2 consultantgurus – dot – com. I gave up on all those automated solutions that promise to secure me and at some point fail miserably – or are so difficult to configure that the corresponding rocket science degrees are way beyond me 🙂 Write me, and I promise a response. I also duplicate this blog at http://akellamani.blogspot.com – you can post comments there if that is easier!

Categories

  • about me (8)
  • Philosophy (237)
    • Kabir (226)
    • Religion (2)
  • Philosophy and Religion (26)
  • poetry (6)
  • Technology and Management (4)

Recent Posts

  • A Mirror for the Self June 29, 2025
  • Modern Wisdom Echoes June 28, 2025
  • Let Them Laugh at the Start, Not at the End June 27, 2025

Archives

  • June 2025
  • August 2024
  • May 2024
  • April 2024
  • March 2024
  • July 2023
  • April 2023
  • March 2023
  • May 2019
  • January 2019
  • January 2017
  • January 2016
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • July 2014
  • March 2013
  • February 2013
  • September 2012
  • April 2012
  • March 2012
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • July 2010
  • June 2010
  • May 2010
  • March 2010
  • December 2009
  • November 2009
  • September 2009
  • August 2009
  • July 2009
  • May 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • September 2008
  • September 2007
  • August 2007
  • February 2007
  • May 2006
  • January 2006
  • June 2005
  • February 2005
  • January 2005
  • February 2004
  • January 2004
  • July 2003
June 2025
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
30  
« Aug    

Categories

  • about me (8)
  • Kabir (226)
  • Philosophy (237)
  • Philosophy and Religion (26)
  • poetry (6)
  • Religion (2)
  • Technology and Management (4)

Archives

© 2025 Ramblings of another geek | Powered by Superbs Personal Blog theme