July 8th, 2008
Information Security is still in its infancy as far as being its own entity inside of any corporation and even more so inside of any government organization. While there are many views on who and what makes a good Chief Security Officer (CSO) or even for that matter if you should have a CSO or Chief Information Security Officer (CISO), there are some tenants that everyone agrees upon without hesitation.
In this series of articles I will be exploring the foundation principles of a good Information Security Practice. In this installment, I will be focused on the traits and key points of a good and successful CSO/CISO candidate.
Your Information Security Practice is often called upon to perform several fundamental functions, some are precursors for, or are sometimes done in the absence of, a Global Audit Group. If you are publicly traded in the United States, your Information Technology department, those people who have the “Keys to the Kingdom”, are to be audited and have many degrees of restrictions and procedures added to their processes. These I will cover in a later paper. But your CSO/CISO is the one who is responsible for ensuring that there is a strong relationship between him/herself and their counterpart in the IT department.
Like any authority figure, especially one that must not only enforce but also produce and custom tailor policy and regulations, your head of security must be of the highest moral character. Those companies that afford the CSO/CISO true “C-level” rank and privileges do so because they hold this position to the same Code of Ethics as any of their other Sr. Vice Presidents or Presidents. The grand majority of companies in today’s environment have the head of security reporting into various divisions of the company, but most likely have this person titled as a Director or Sr. Director, or a lower-level VP. Personally, I would argue that the importance of the Practice and impact on the Stock Holders and profitability of the company would warrant direct reporting to the CEO, but as of yet only a handful of companies have started doing this.
The surge in hiring for the CSO/CISO position has come with several levels of enthusiasm from the companies hiring such a person and building such a practice. You have companies that wish to check the box for the new “C-level” position simply to say “yea we have one of those” as they did many years ago for a CIO, and much like that time no one is quite certain what their CSO/CISO should be doing. You have companies, especially financial groups, that have a very clear vision of what their new CSO/CISO should be responsible for, but may or may not empower them to do these things as they are not sure where the person should be reporting. While I won’t argue a company’s vision on its command chain, I will take the time to point out having the CSO/CISO reporting to the CIO is a little like having your head of financial audit reporting to your CFO. You can’t really audit and take action against your own boss, and anyone could argue there is a massive conflict of interests.
Also causing issues is the mass of so-called “experts” now appearing on the horizon, and quite sadly the increase of people with very embellished resumes. While I can’t draw for you the perfect generic image of a CSO/CISO that would fit in your company, I can outline some items to watch out for and some items to keep in mind when making your selection. You see, much like the development of your company’s security practices and policies, your head of security must be a good cultural fit that takes into account your particular business market. If you have a creative company then having a draconian security czar is probably not the way to go. Likewise, if you have a company that must adhere to very stringent regulations and handles sensitive information you probably don’t want the person who likes to make exceptions in the policies for anyone who asks.
First, let’s discuss items to watch out for on a resume. I will try to make something quite clear, Information Security is not like Information Technology where you see people hopping from one company to another to increase their pay or position. Information Security is more akin to your Legal department, and for many of the same reasons. You need people that you trust, that have the highest creditability and integrity, and that are very well versed in their area of expertise. More to the point, your Information Security Practice is indeed an amalgam of Legal and IT. They must understand and stay abreast of legislation, Information Technology trends and advancements, and understand your business model / functions.
Unlike your IT department, it is quite likely that your Information Security department will end up on a witness stand or in a courtroom presenting information or testimony on your company’s behalf. This means their character can, and of course will, be called into question. If someone needs to understand a business, I would safely argue it takes a year or more just to understand the ins-and-outs of that business. So if the person you are looking at has spent less than a few years at their places of employ this should raise flags for you. Likewise, the head of a security practice has to be able to say “no” to co-workers, executives, and even at times the Board of Directors. It may very well be that if you are looking at a person with only a year or so at all their last employers you are seeing someone who lacks the political savvy necessary to tell someone “no” while providing them with an alternate solution and the same time making the person believe it was their idea to begin with.
Affiliations in security groups is an interesting topic. With the exception of a few, membership takes only one email to a list server to subscribe and be part of the group. Review the memberships that a person holds and think over the following: Do any of these groups directly relate to increased security awareness or skills in my company? Are any of these groups providing accreditation of the applicant you are reviewing? Do any of these not look right?
Affiliation to Government and Law Enforcement is something I see more and more on job descriptions. Be cognitive of what you are asking for when you post such a requirement. In most cases you, the hiring company, are looking for someone who has had experience in interacting with State and Federal Law Enforcement in a prior job as part of their duties in Information Security. So someone listing that they were the liaison for such communication and relations is what you are after. If you are looking at a person who has no Law Enforcement background, and they are listing they are working for or have worked with a federal agency you might want to dig into exactly what they were doing and gain a contact name that can validate this statement.
I have personally seen people list that they are “advisors” to the FBI, for instance, and this is a title that they themselves have appointed as the FBI does not take on civilian advisors except in very rare cases. Even those who have been such advisors will tell you the documents they had to sign with the FBI do not permit them to claim they ever worked for the FBI. Also watch out for people listing membership in “task forces.” While there may be some civilians on such a task force, most all such groups are exactly what you would envision if I said “Drug Enforcement Task Force.” They are Officers and Agents assigned as resources to investigate and make arrests.
Papers and writings are key when you are looking for someone at this level. While you may not be shopping for the best White Hat Hacker available, you do want someone who is active in the Information Security world as this will assist in vendor management, technology knowledge and future staffing. This may mean they do a lot of speaking rather than writing, but again you should vet and check on these things. Writings are easy, especially if the person is like me and maintains a website full of Information Security blogs and has published papers. If your candidate is a frequent speaker I suggest going and attending one of their lectures.
Ask audience participants what they thought of the talk, and get other general feedback. You might just learn the guy you really wanted to hire is considered a quack and the audience was there in large part for the entertainment factor. I once attend a talk on forensics by a so-called expert because I knew he had recently been removed from the witness stand and his “expert” accreditation from the court was revoked. I found his talk, being an expert in forensics myself, to be off-the-wall and quite humorous and sad all at the same time. This same individual, who’s name I won’t reveal out of courtesy, also claimed association with the FBI and other government groups and went so far as to say he had helped close many high-profile cases.
It was strange how his entire lecture went away from his slides and the chest pounding ended when a group of men in dark suits walked into the back of the room and stood there waiting for him to finish talking so they could escort him to a car waiting out front. Remember, claiming employment and association with such groups when it doesn’t exist is a felony. And holding a lecture where you purport to be such after being warned not to is frankly quite ignorant of the outcome. You as the hiring company don’t want your future CSO/CISO being charged with such a thing, or worse yet having such purported associations made on public documents (resumes, blogs, etc.) being called into evidence during a Senate Hearing ala Enron… aka a SOX Hearing.
It seems odd that I would have to make the next statement, but do perform a background check. I can’t stress this enough, and I know so many people just want to trust the person they are hiring is indeed the person they say they are. But look at who/what you are looking for when you tap into this world. Information Security has always had, and always will have, undertones that whisper “hacker.” Social engineering is a cornerstone talent used by people in my world. Frankly I have gotten quite far into a network, after being hired to do so of course, by literally talking my way past people to get their credentials to enter.
Kevin Mitnick’s famous (infamous?) hack was mostly all social engineering. Recently a very large security vendor in the Bay Area hired a CSO who knew a thing or two about Social Engineering. The man worked at the company for six months as their CSO, and while some people had suspicions he was not capable of the job, his resume spoke volumes for what he should be able to do and he was hired after putting on a great show at the interviews with his fine resume punching tickets the entire way. No real background check was performed, and it turned out that not only did the person falsify their entire resume, but they also stole the identity of another individual while doing it! This probably would be one of those “bad” things for you to discover when your CSO/CISO is sitting before Congress telling them that your SOX compliance audits were indeed performed correctly and the SEC is “just misinformed.”
Calling past employers and checking out the basics like job description, pay rate, etc. is a nice start to a background check. And if this were hiring Jonnie in the mail room, you could stop at this step and consider it a job well done. I would argue that anyone hired at a “C-Level” job be put through the same level of background check that say a police officer or federal agent is subjected to. Not just a reference check. Literally go over every aspect they list on their resume, use Google to research and find not only information but people that can talk to you. In the case of the Bay Area Company, simply using Google to find photos of the well established person whose identity was stolen by their CSO would have been enough to prevent the embarrassment of hiring that person. Again all public papers, public speaking engagements, development teams, etc are posted and easily searchable online. Finding skeletons in the closets now is always better than having someone force your eyes open when they rip the doors off a closet for you later.
Your Information Security Practice, every last person in it, will be called upon to make statements, even if just internally, about wrong doings of members of your staff ranging from entry level to Chief Officers. With E-Discovery on the rise, and accountability for compliance regulations such as SOX, PCI, etc all falling to these groups, their integrity will be of paramount importance when giving testimony and the fact that their very signatures accounting for compliance are what is being trusted by the federal agencies who govern these policies. We have all watched the police drama where a police officer or detective goes bad or has something from his past uncovered and all of his cases and convictions come into question. The same could happen here, but of course with dire civil consequences.
And while we may all internally argue over where Information Security should report, what its exact responsibilities should be, and who makes a good candidate for a CSO/CISO, it should go without saying that a righteous character and upstanding degree of integrity are prerequisites for any candidate.
I hope you enjoyed this short write-up and come back for the next installment where I will be talking about policy and corporate culture.
Policy Development and tailoring it to your Corporate Culture.
I have done a lot of speaking over the years. And inevitably I am asked, quite often, to speak about successfully running and building a security practice in a large corporation. One of the things that I always harp on is something I learned so many years ago when I played football in high school. “If you don’t master and then continue to practice tackle and blocking you won’t have a passing game let alone a running game!” This seems to apply to may things in life, and it boils down to a simple truth… if you don’t have the basics done then doing anything advanced will be a fruitless effort.
To that point, I often bring attention to the most basic of elements for any company that desires to get a grip on its security. That of course is a Security Policy. Now so many people cringe at that phrase, and while I am still disheartened when I learn a company I am contracted to help with doesn’t have such a policy I am not all that shocked to discover it.
When you really get down to it, normally after the last excuse in favor of further procrastination has passed, you learn a policy is quite a valuable tool. It does a lot more than just establishing rules and procedures, it is actually one heck of a way to market Information Security in your organization and build business continuity (e.g. “make friends and gain allies”) with your peers.
I was once asked by a consultant who was reviewing the IT Organization, how it was possible that I was able to secure so much Intellectual Property (IP) in such a large global company with so few employees working for me. My answer seemed to floor the poor guy. I told him that I marketed and worked the idea that every employee of the company is responsible for information security and thus the protection of the company’s intellectual property. The other supporting structure that allowed for this was that the Security Policy for the company was developed from a standpoint of supporting and ingraining itself into the culture of the company. Likewise, I didn’t just go and sequester myself and reappear one day holding a list of commandments proclaiming that I had developed a policy, or more correctly what most people might view as a long list of ways to get fired.
So here is a little story, and perhaps you can glean some good strategy from it… I, of course, will cut out most of my blunders in order to paint myself as being far wiser than I really am.
So for those of you who have read my resume, heard me speak, or just happen to know who I am you know I worked at Electronic Arts Inc. for quite a long time. During that time I wrote two separate security policies, the first being greatly ignored by most everyone in the company and the second happened to earn the notable feature of being only one of three true global documents or policies in the company. Upon these policies I built the practice. But here are my rules, learned after running into quite a few brick walls, about writing any policy:
- No rule shall be written that cannot be enforced at the time the policy is written.
- No rule shall be written which prevents someone from doing their job.
- No rule shall be written that conflicts with the culture and goals of the organization.
- No rule shall be written which tells someone they “may not” “shall not” “cannot” etc. do something.
- Keep it short, sweet, and consumable.
Really each of these rules came with a hard lesson, but I think I will skip that and move on to the “why” behind each one. Fist let’s address not wring a rule that cannot be enforced.
It seems a bit odd that many organizations have policies / protocols that prohibit their employees from doing something, or mandate that something be done exactly as outlined, and yet there is no system or tool installed to ensure that these policies are being adhered to per that same protocol. You have a major issue here if you happen to take action against Employee “A” and it can be shown that you never took action against Employees “B” to “Z” for the exact same thing. Similarly, if you have a policy that for example says “You may not access external email systems via IMAP or POP” and you don’t setup some form of protocol blocking to enforce this then those people who notice this will of course go testing all the other policies.
So rather than put a big red blinking sign up, you might want to just keep your head low until you are prepared to make such a policy statement. I have had some people argue that they have to have some items listed in their policies to meet SOX or some other compliance audit requirements. While this is true, it only drives home the importance of my first rule. What happens now when you are audited and although you have a rule saying “all passwords will be changed every sixty days and must be strong passwords…” but when tested none of your systems support enforcing such an action? Which was worse, the lack of a statement in your policy or an operational failure during the audit? Enough of that one, let’s move on to preventing people from doing their jobs.
I know countless stories of Security Departments that enact some policy and technology because they, or perhaps the IT Department, decided that whatever they ended up blocking was a major security risk. Then, quite unplanned, the Vice President of Firing People and Yelling is standing in the CSO’s office wanting to know why Instant Messaging was blocked as it is the primary means of communicating with the customers or some external development team. If you would like to skip this embarrassing lesson, it might benefit you to spend time with your customers and understand all the details around how they perform their jobs. Sticking to the IM scenario,
I, and probably any security practitioner worth their salt, could argue night and day on the reasons a company should block all forms of IM. But in taking a reality check and understanding how my customers do business and collaborate with external (e.g. third-party) developers it becomes acutely apparently that blocking IM would impede their effectiveness if not the overall capability of the company. With closer examination and a true assessment of the risk factors, it was clear that the risk exposure from these key developers of the company’s main product was actually quite small.
Conversely there were greater risks from other categories of employees using this same Internet service. And thus a policy and technology to permit graduations of IM application usage from completely banned to feature-full usage was developed. Then again, I have never been a fan of “turn it off and see who complains” as a means to rank the value of an application or service. Others still like that method… And now let’s go over the human aspect.
I draw your attention to the Penal and Transportation / Traffic Code in your state, country, city, whatever. You will notice when reading the laws as actually written there are few of them written from a standpoint of what you can’t do. Those that are written that way relate to contraband. For the most part, the laws (especially say traffic laws) outline what you may do and in what manor you may do them. This is actually quite smart for two reasons. First, people are far more responsive if you tell them what they are allowed to do.
Second, it is very much a white-list approach to policy. You aren’t going to be writing an endless list of things people are not allowed to do, and you aren’t going to get jammed-up every time you try taking action against an employee who has a high probability of saying “well no one told me I wasn’t allowed to do that.” Instead you start your policy by stating that employees are only allowed to use the network, their computers, etc. as outlined in this policy. It should also state that any assumption of having permission to do something which is not outlined may result in disciplinary action up to and including termination. And finally, how to ensure people read the darn policy.
Earlier I stated I had written two global policies, and that the first was not well received. After checking into it, I discovered one of the primary reasons was because the document was over thirty pages long. And while I love Information Security, Information Technology, and protocols the average person you work with probably doesn’t care to get more involved Information Security than say I do with the how exactly my dentist is going to fix a broken tooth. I care in as much as it might cause me pain, but as long as the outcome is a good looking tooth I could care less what they need to do.
Keeping the document short and sweet is vital. Keeping the tone of the writing within the due bounds of the culture of the company is also vital. If you are writing the policy for a double-secret- encoder-ring government group that only houses people with “Top Secret with Clusters” level of security, than you can get away with being quite stern and direct with your wording. If you happen to be writing the policy for a very liberal, fun loving, easy going workplace you might want to ensure your message is delivered with plenty of honey and it is warm and friendly. It goes back to the main purpose of writing the document which is people read it; accept it and it grows into part of the culture.
That last ingredient after all the rules are followed is to ensure that you have input from other people in the company who want ownership in the document and practice You aren’t going to get far if the business owners find out about the new policy when you bushwhack them with it in a CXO meeting. Or even better, when you are in the business leader’s office consulting on the termination of one of their employees. You also aren’t going to have them signing onto your policy if Legal, H/R, etc. haven’t already looked it over.
H/R can help you with the cultural aspects and the wording to ensure it fits the culture. Legal is necessary to not only ensure you aren’t breaking any privacy laws, but also any employment laws. They will also want to play with the wording of your document because well… they are lawyers and that is what they do. My suggestion in this case is to let Legal and H/R deal directly with one another over the final wording. No need to make enemies with anyone in your two most important support departments.
So now you have a short (aka “consumable”), properly worded, and direct document. But what about all the technical stuff that is missing? Well, again I have to reference my dentist analogy. Given that you work at an average company with maybe less than 1% of the company working in Information Technologies, that means 99% of the people reading your document aren’t going to care, understand or want to read anything more technical.
My suggestion are supplemental policy documents that are written for, and directed to the activities of, the IT department. These would be hardening documents, your protocols around password ageing, retention, lockout etc. for application development, and so forth. Other fun documents to add might be time synchronization, VPN and other critical architecture policies, process control for onboarding and offboarding of accounts… you know, all those fun things you really should have so you can consult and help your IT / IS departments.
Having a Technical Writer isn’t a bad idea either. You need to ensure wording, and you are going to have many critics on policy documents. This leads to another strong point to make sure of; that ensuring that you have the best person on your staff working on the specific policy or section a policy. That is to say, if this is a very technical policy then have your person with the strongest command of that discipline working with the writer. If you have a strong business development background and are a great administrator then you probably already know you don’t have the where-with-all to go deep tech. If you are deep tech you probably don’t realize your document isn’t consumable by non-tech people. And if you are the diamond in the rough that has a strong command in both directions, write to me so we can form a support group.
Until next time…Thanks for reading..Best Regards - Frank Artes.
Originally published at http://www.lovemytool.com/blog/2008/07/francisco_artes.html
Posted in Uncategorized | No Comments » |
