I received a hilarious email posted to the security-basics mailing list this morning that I had to share:

I was in a bar in San Francisco where my English accent has a habit of stimulating conversation with total strangers, in this case it was with a webmaster (sadly not webmistress) of a dubious website hosted in Amsterdam (I don’t think I need to expand on the nature of the site;) I mentioned that I was passionate about Information Security, whereupon, he proceeded to tell me his root password, as he was so proud about how hard it would be to crack! If this was an isolated incident I wouldn’t mention it.

However, these instances are becoming ever more frequent, is it my trustworthy face or are others experiencing similar errors of judgement?

Special thanks to Andy Cuff, the originator of this email and CEO/Founder of The Taliskar Security Wizardry site, for making my day.

The illustrious Shon Harris has stated in her latest article for SearchSecurity.com that:

Not only should the networking group and security group have distinct and clearly defined tasks and responsibilities, but they should also have separate chains of command.

which I agree with completely. Her next comment, however, is another story:

Problems can occur when sharing the same chain of command. For instance, let’s say someone in security informs a network administrator that there is an unsafe rule set on the firewall. This traffic setting, though, may have been implemented by the network administrator to support a business need or a user’s particular preference. There is a chance then that the administrator may rank the network concerns more of a priority than the security issue and ignore the information.

This sounds like a documentation or process failure to me and not one related to the sharing of the same chain of command. If the rule is required to fulfill a business requirement then it should be documented as such and made available in times of need (like for auditing purposes).

Her final point suggests introducing an intermediary, in the form of a security engineer, to help open the communications channels between the two groups:

The network lab manager and the CSO should perform their duties separately. If the CSO needs help, then a security engineer should be hired to properly arrange the responsibilities.

I’m not sure if this is the right approach or not. Hiring a subordinate to manage the channels between two groups may result in a power play for the engineers favor. Also, there is nothing in the article suggesting to whom this security engineer would report, which may cause even more internal conflict between the two groups.

A better suggestion might be to hire an experienced security project manager who has experience in both networking and security. This person could have a dotted-line to both the CSO and network lab manager for these types of issues and could report directly to the COO to eliminate the aforementioned conflicts.

One final thought…

If these two groups cannot work together during the course of a regular business day what hope do they have of handling an incident when it occurs in a timely and organized manner?

P.S. Hopefully the ‘security gods’ don’t strike me down for crossing Shon Harris…love your book…