Do infosec engineers live in ivory towers?

Okay - own up, infosec engineers - do you train in the business process and understand the relevance of business need for survival?

Most of the engineering I have seen seems to have little relevance to or understanding of ground reality - is this endemic? For example - Risk Management and Information Security will spend days closeted with security vendors and their offered toys - and come up with new designs centered on their toys of choice for the *new and improved* infrastructure security model – with little to scant attention paid to how this will translate to reality. There is little indication for a proper upgrade/replacement path, no attention to forward facing support structures, no explanation for ROI and scant information on what to do with the current setup in place or why it is no longer good enough.

Would this explain the lack of respect for most IT and IS outfits in business circles? Would this be a reason businesses tend to treat IT as an exotic toy that can enable business, but can be dropped like hot potatoes at the first sign of financial distress? Are we responsible for our lack of appreciation of digital information handling as a true business enabler instead of just another tool?

If those are the questions, here are some suggestionsJ!

1) Involve business and production support in the requirements gathering and the design process from the beginning.

2) Understand the business drivers that are funding the current infrastructure, and relate the change and its cost to these drivers. A solution that costs more that the expected return will end up in the gutter every time!

3) Understand at least the basic accounting principles that the firm uses – depreciation, asset classes and expense classification are good starters. Use these to present the offering in language that the bean counters will understand (and do not look down on them – they are the ones that been the business moving forward on the financial path even as marketing and sales do their own wonders – this is the grease that smoothens the path after all – and no money = no job pretty soon!)

4) Understand compliance needs. The latest security gadget might not fit after all if the logging schema requires a full redesign to accommodate compliance and audit requirements.

5) Support – can the new stuff all be supported once in? What is the associated cost there? Do the support teams need training? When will this happen? Can the shifts all have proper representation at training while still manning the fort? What is the escalation process? Who is responsible for design updates after the product is in production? Will engineering offer sufficient support for the teething period in the initial production days? How will this commitment affect other engineering work?

Okay – all questions are answered to everyone’s satisfaction, and the project is ready for rollout. Now for the BIG question – is it still required?

To quite Benjamin Disraeli (from the last phrase of his book – Coningsby ) – “They stand now on the threshold of public life. They are in the leash, but in a moment they will be slipped. What will be their fate? Will they maintain in august assemblies and high places the great truths which, in study and in solitude, they have embraced? Or will their courage exhaust itself in the struggle, their enthusiasm evaporate before hollow-hearted ridicule, their generous impulses yield with a vulgar catastrophe to the tawdry temptations of a low ambition? Will their skilled intelligence subside into being the adroit tool of a corrupt party? Will Vanity confound their fortunes, or Jealousy wither their sympathies? Or will they remain brave, single, and true; refuse to bow before shadows and worship phrases; sensible of the greatness of their position, recognise the greatness of their duties; denounce to a perplexed and disheartened world the frigid theories of a generalising age that have destroyed the individuality of man, and restore the happiness of their country by believing in their own energies, and daring to be great?”

Project management in the security space - trials and travails

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!

I would love to hear other's project management tales and experiences. So please share if you can!

Some thoughts on understanding the people value in a Information Security team
Where is the new internet world headed? Complexity begets an accompanying loss of assurable security, as is evidenced by all the unhappy digital break-in news around us. There is even lesser comfort in the fact that most of the software out today is was never designed with security in mind, and is today uncomfortably ensconced in an ostensibly protective cocoon of security devices, that seem to work more to prevent the application from working rather than prevent it from attack.
Our biggest shortfall today seems to be our lack of recognition that what we know is not even the tip of the iceberg - and yet most leaders and managers focus on just that little tidbit and ignore the larger danger of the unknown and undefined lurking below. In this headlong rush to cut costs while maintaining operations, the easiest win SEEMS to be to automate functions and drop head count, but that is the worst thing to do in the security domain. The big losses are:

1. Loss of institutional knowledge that seasoned warriors have, that will take newbies ages to learn
2. Automated scanners and detectors can only recognize known attacks - they are helpless against the unknown or zero-day attacks and vulnerabilities
3. Today's fuzzy logic solutions are not seasoned solutions. While they represent cutting edge technology, they still have to be field proven - and do you want to be the one providing the field test opportunity, especially with the crown jewels of your digital assets at stake?
   

Automated solutions can at best complement a well-rounded security team - they cannot replace them (not yet, anyways!).