A ship in harbor is safe, but that is not what ships are built for.
—John A. Shedd
Many years ago, the CTO asked me to a give a five-minute presentation to the rest of executive leadership regarding the recent risk analysis my team had completed. It was a huge project for the security team, spanning months of work examining every possible IT risk to the company we could imagine. The final report was nearly 50 pages long, filled with quantitative details on multiple sources of threats and multifaceted impact calculations. This was my first appearance before the entire executive team in a single room. Since I had only five minutes, I condensed our results into a handful of slides covering the top three risks. I arrived early and set up my laptop and the projector. As the execs strode into the boardroom, the CEO noticed my title page, “The Top Risks to the Company.” He asked as he sat down, “Oh, you’re going to talk about our competition?”
I was stunned. No, my presentation covered things like earthquakes, stolen laptops, and malware. More importantly, he was right. I was the tail wagging the dog. IT security risk is important, but it might not represent any of the top risks to the company. We were a growing startup just starting to gain traction in the marketplace. Losing enough key sales could mean a downward slide for the entire venture. It was an epiphany for me. Security is there to serve the business, not the other way around.
Ultimately, I did come to understand that security was important for the organization, but only because it was important to customers. Having strong protections in place to guarantee privacy and availability were good, being able to demonstrate to the outside world was better. After that, I framed all my messaging that way. This meant in addition to building a strong security program, I would pursue audits and certifications for the sales and marketing team to show off. When I talked to management, I emphasized the effect a breach would have on corporate reputation. I would talk up how a security project could provide new secure customer services and raise reliability. I studied our competitors’ security efforts and made sure that we matched or exceeded them. Once I knew what mattered to the organization and aligned my work accordingly, I had no trouble getting budget or support for my security program.
When Security Appears to be Anti-Business
IT security and audit sometimes have the reputation for being anti-business. It isn’t hard for me to rattle off a list of common complaints .
Security puts us behind the curve. You block new technology all the time with the reason “because it isn’t safe.”
Security always says “No!” They kill so many good ideas. Now we don’t even tell them what we’re doing anymore.
Security is sore loser. When their objections are overridden, they say things like, “You’re going to do that insecure thing even after we told you how dangerous it is? You’ll be sorry…”
Security yells at us when we’re the victims. I was just surfing the Web trying to find something and my browser got hacked. Now I don’t have my laptop and I’m being told I was a careless newbie.
Security is always pushing obsolete and convoluted solutions down our throat, like making us create and remember weird passwords or making us patch all the time. My computer spends more time patching than doing useful work.
The worst is when security is seen as the Department of No. It’s easy to see how a lot of that happens. Business units are often told to find new ways to make customers happy with no restrictions on IT risk or compliance requirements. If security doesn’t find out until after something is already rolling along with a lot of organizational momentum, then the security requirements appears as the obstacle. The security team is seen to rush in and try to put the brakes on before something terrible happens. Sometimes it seems like management, by accident or design, has set up an adversarial relationship. It’s a tough burden to be the person telling people they can’t do something. But isn’t security the final word on what happens or doesn’t happen?
Who Really Decides?
The ISMS steering committee represents the leadership of the organization. If the committee was formed properly, there is either executive management in the committee, or they have the authority of management. There may also be times when members of the committee would present results and decisions to the entire leadership of the organization, such as the board of directors or CEO. The entire point of the steering committee is to make sure IT security properly supports and empowers the organization’s business. IT security’s role in all of this is to present and explain IT security issues so that leadership can decide what to do about them.
Security explains what needs to be done, laying out the costs, the reasons, and the timing. Leadership, through the committee or alone, decides on a course of action. Sometimes that action could be too risky for the security representative. In that case, the security officer needs make the matter clear with no misunderstanding. Ending that misunderstanding is a critical part of the security job. Once matters are understood, if management still decides otherwise, then that’s what the organization wants. Like it or lump it, that’s the way it is.
Likewise, security solutions must fit the culture of the organization. IT is there to fulfill their needs and run business processes, which means taking on risky behavior. To succeed, sometimes organizations have to push beyond the safe boundaries and do risky things.
Since every organization is different, how does the security team find this understanding and make use of it?
Understanding the Organization
The obligation is on the security team to understand the organization, not the other way around. If by luck, the organization is willing to learn and understand IT security, then the security team must do its patient best to explain things to them as many times and as many ways as they are willing to endure. The security team should not speak in terms of IT security, remembering that even words like “risk” may have a different meaning. In finance, risk can be seen as attractive because high risk often entails high reward. You must translate things into the language of the organization. How do you do that? By finding out what is important and exploring how security affects organizational goals. You begin by asking.
How to Ask
Before learning what to ask, it’s important that you understand how to ask. Many IT security professionals used to be IT professionals, and very few IT professionals are famous for their charm and charisma. Speaking to machines all day will do that to you. So let’s go over a few basics on asking questions.
The first rule is obvious but is still worth stating: when you ask a question, be sure to listen to the answer. While they are speaking (even if you didn’t ask a question), take notes, preferably on paper. Do not type answers into a device. It’s distracting, slow, noisy, and people may think you’re reading your e-mail. Write notes on paper or pay close attention and remember. Listen to their entire answer before you speak again. Speaking of speaking again, if they’re describing a problem, it’s not helpful to try to top their problem with a bigger problem of your own. This is an investigation, not a complaint competition. After they describe their problem, you may either ask a question related to what they’ve just said or confirm that this is everything. If they are done, summarize what they’ve just told you in your own words. Not only is this good for understanding of the issue, but it builds rapport with the other person. Note that this technique is useful beyond asking questions of executive leadership. It is useful for a broad range of communication with humans and humanoid life forms. It’s worth practicing, even if you think you’ve mastered it. You can also work on ascertaining how confident or satisfied they are in the answer they are providing.
Who Do You Ask
When learning about an organization and its processes, anyone is fair game. You definitely should ask your boss and your peers. When you’re doing your risk, asset, and compliance analyses, you’ll have a great excuse to talk to every major department head. The same goes if you’re working on a business continuity plan. Whatever your organization does, that is whatever customers it serves, you should definitely talk to as many of the people directly involved in that process chain. Sometimes this is easy if an organization is a for-profit business , you just follow the money. For academic institutions, you should talk to the teachers and librarians. If you’re completely bereft of ideas, hit up HR and get an organizational chart to review for ideas. Not everyone will have all the answers (although the senior leadership might come close), but a thorough process of investigation will get you most of the answers. Keep in mind the “I” in IT. Data flow also provides insight here. Wherever the “I” moves around, and whoever touches it, may have something interesting to tell you.
What to Ask
Now, what do you need to know? Here’s a list of things that you can ask straight out or try to figure out based on descriptions of the business.
What is the business model?
How do we get revenue to operate? How does it happen? When does it come in?
How do we lose money?
How important is agility or the ability for the organization to change processes quickly?
How important is organizational stability? Do we rely on having cash reserves or credit? Do we live hand to mouth from sales?
What is the organization’s secret sauce?
What are the things we do that no one else can do?
Does it involve intellectual property ?
Does it involve particular expertise?
Does it involve unique processes?
Do we have special government mandates to do things that other organizations can’t?
Does our organization or business model depend on consumer trust ?
What information do people need to do their job?
Which processes need what information and when?
How do they get it?
What happens if they don’t get it?
What happens if it’s inaccurate?
What happens if it’s seen by a third party?
What are the biggest challenges facing the organization as a whole?
Growth? Survival? New markets? Changing regulations? Competition? Shrinking customer base? Shrinking budget from legislature?
Who does the organization serve?
Who are the current customers?
Who are the biggest customers and what do they want?
What do the majority of the smaller customers want?
Who are the customers that aren’t worth having as customers?
What customers do they want to go after?
Where is the organization going?
What do we all hope happens? How does the organization define success? What could stop us from getting there?
What are the biggest problems right now?
Are we planning on growing? If so how? New locations? Bigger sizes? Acquisitions and mergers?
What are the major internal systems or processes?
How do we handle sales and revenue?
How do we purchase goods and services ?
How do we circulate information internally?
What physical locations do we have presence? Don’t forget unmanned storage facilities and data centers.
How do we communicate with customers and outside entities ?
How do we onboard and terminate employees? Contractors? Interns?
Who are our key partners and suppliers? What do they do for us? How do we work with them? How do we bring them on? How do we remove them?
What do we do with legacy information and systems? Is there an asset life cycle?
What IT equipment do we own? Rent/lease? Outsource? Do users BYOD (bring your own device )?
What are the major IT projects planned for the next few cycles? What problem are they trying to solve?
What to Do with This
Once you’ve gathered this information, the question to ask yourself is how can security help with these things? What should you be spending your time on? Sometimes what is important is completely non-intuitive to a techie. For example, in some companies, the sales department’s priorities are higher than the operation’s priorities.
How does the security team become an active participant in driving new technology and innovation for the business and IT-side of the house? As organizations grope into the dark future, IT security can shed some light about potential obstacles. In this way, IT security can allow the organization to move faster and avoid pitfalls.
Answering Questions
The other side of asking questions is answering them. When you present risks, you can expect there will be questions. You also need to expend resources to implement security controls, so you need some combination of money or time (which is also money, per the ancient maxim). If you’ve ever experienced asking executive management for money, you know how difficult it can be. As my favorite superhero, Too Much Coffee Man,1 says: “In the land of toast, the butter is spread very thin.” So how do you justify your request?
Do the Researc h
If you’re proposing to do something that is going to cost serious money, you had better have your facts straight. By facts, I mean evidence as hard as you can get it. Quantitative analysis beats qualitative because actual numbers and dollars are what executives are used to dealing with. Nothing sounds more wishy-washy than something bad might happen, or worse, saying that you need a hundred grand because the risk is yellow-orange instead of green.
If you’re implementing a control, have a good idea about how much risk reduction you’re getting and why. Lay out the costs of the control, including the initial costs and ongoing cost. Include hard costs (what you’re going to pay in dollars) and soft costs (how it impacts staff and process). Show them the calculations and the data sources that you used. Present alternatives so that they can see what they’re trading off against. Compare this to peers in the industry. Explain the value of your defense in clear terms they can understand.
Bad: We need a new Razorwall firewall because, otherwise, we’ll get hacked and all our data will get pwned. IT is doing a lousy job locking those boxes down, so we need more technology to make up for it.
Good: We currently have a high risk of Internet penetration across all of our customer-facing web sites. We’ve tried patching, but IT just can’t keep up with the new vulnerabilities. We want to put in a smarter firewall that will automatically block most of these attacks before they reach the web site. It’ll cost us $27,000 to install and another $5,000 a year to maintain. It’s the cheapest alternative we’ve found. We already have people in IT who are familiar with this technology, so installation and maintenance is a slam-dunk.
Better: Our last penetration test showed 16 critical vulnerabilities on our corporate and marketing web sites. Based on this information and industry averages, there is a 50% chance in the next six months that our sites will be broken into and defaced. Worse, hackers could use our sites to host malware, which means we could be infecting our customers who visit our site. IT needs nearly three weeks to schedule, test, and completely patch the web site each cycle while new vulnerabilities appear at a rate of four per month. We have several ideas on how to take care of this. IT is looking into speeding up their patch cycle, but they said they need more personnel. The IT director is planning to submit a proposal to you on that. I am recommending a better firewall for the web site to buy us mor e time to complete patching. It will also protect us against other threats as well as support new web site services as we roll them out. I have a detailed project plan and budget for the firewall, but the initial cost will be $27,000 in the first year and $5,000 per year after that. Another alternative would be to have someone else host our web site. I have some numbers on that if you’re interested.
Don’t Wander Outside Your Area of Expertise
When confronted with questions you can’t answer, don’t try to make stuff up. If you’re basing your answer on hearsay (something someone else told you), then say so. We all can’t be experts in everything. Even security is a wide and deep field with many disciplines and details. If you don’t know or aren’t sure, tell them so and that you’ll get back to them with a definitive answer. And then get back to them. There is nothing wrong with “I don’t know but I’ll find out.” As the saying goes, better to remain silent and be thought a fool, than to speak and to remove all doubt. This is especially true with the world of finance. I have seen security project proposals rejected because of incorrect return on investment (ROI) financial models.
How to Talk Their Talk
It’s hard enough to do the job of keeping hackers out and auditors pleased. Don’t add communication problems to your list. You should communicate on their terms, not yours. Speak in language that they understand, not with a lot of technical jargon. If you’re going to use jargon, use jargon that’s part of the culture of the organization.
When speaking to executives, match the medium of their preferred mode of communication. Since leadership primarily communicates with their voices, face to face, then that’s likely how you should communicate. If you send a long e-mail full of technical details, it’s unlikely that it will be read in a timely manner, if at all. I’ve found the best way to communicate is to talk in person in a brief meeting and then follow up with summarizing notes.
You should always try to communicate in a business-positive manner. This means getting away from saying, “No, you can’t do that! We’ll get hacked!” and moving toward, “Here’s a better way to do that,” or “If we do it this way, we can go faster and take on more risk in this area, which could give us a competitive advantage.” Here’s an example:
Bad: “Marketing’s new web site uses 56 bit SSL. That crypto is broken and isn’t PCI compliant. We need to halt that project right away and get it fixed.”
Good: “It’s come to my attention that Marketing’s new project, the gift shop web site, is using weak and obsolete encryption. This could be a problem if anyone expects their communication to remain secret. I believe that there is an option for customers to enter payment card numbers on the site, so we could be facing PCI DSS audit sanctions. I’d like to work with IT and Marketing to upgrade the encryption. This may slow down the project, but this fix should be pretty easy to install.”
Better: “For any customer-facing web site that asks for payment card numbers, we always use newer encryption systems. Our customer’s expect us to do a quality job securing their data and it reduces our legal exposure. Furthermore, upgrading encryption doesn’t cost us any hard dollars, it’s just a configuration option. Now, I believe there are a few new web projects that aren’t meeting this standard. I’d like to work with Marketing and IT to resolve this…”
In the final example, I focused on setting a high standard of quality for customers. Only then did I move on to the potential deviation, immediately weaving in a solution. I would expect the response to this to be a nod and a wave to move on. I also didn’t propose halting the project, since this kind of thing is usually fixable a matter of hours, once you get the right people involved. If I get push back, then I’d explain how I have the backing from leadership to get this done right away.
When going into a meeting with leadership, have a printed agenda to hand them. Bonus points if you included the agenda in the meeting invitation. I like to hand them a paper agenda so they can make notes on it while I’m speaking. In addition, it’s a nice indicator that I’m organized and not wasting their time. Time is one of the most precious things to executive leadership.
Neutron Star s
A neutron star is a tiny hyper-dense star with immense gravity that affects things millions of miles away. When I convey information upstream, I like to use neutron stars: tightly packed chunks of information with strong ties to important things like customers (money), business objectives (money), or potential expenses (money). I also like to include vivid scenarios and examples that are concrete and have direct consequences. If need to, I’ll cite facts or even pull in outside experts to help support my case.
Explaining Risk
When explaining risk, either to a single executive or to an entire board, it is a good idea to use a multimediated approach. This means presenting orally, in writing, and visually. This doesn’t mean have a bunch of PowerPoint slides with your speech typed up as bullets that you read. This is where your risk models can come in handy, as many of them translate into interesting and informative visuals. For example, Figure 8-1 is a slide explaining a phishing/drive-by web attack.
Figure 8-1. Example visual explaining an attack
Whenever you can, use visuals, analogies, and stories to explain risk. Avoid walls of boring text. Keep things concrete and tie them to dollars as much as you can. You don’t need to do all this work for every single risk that you ever explain. It is a useful thing to do for top risks or explaining a particular nasty new attack that you need resources to remediate.
If you’re talking to any executives with a background in finance or financial audit, you can also talk about risk in terms of assurance. Assurance is a measure of how sure you are something is what it says it is. You may have noticed that the control objective examples given in the scoping chapter used the expression reasonable assurance. Assurance is the good thing that risk erodes but controls reinforce. Therefore, you can talk about risk thresholds in terms of falling below reasonable assurance.
It’s a good idea when presenting a problem to offer solutions. Follow the negative with a positive. This new risk is below our tolerable threshold, but here’s what we can do mitigate it to an acceptable level. Be upbeat and positive. You can solve most of these problems if you think and work hard enough.
Finally, you have to realize that to an executive, some risks are worth taking. Success in business is about taking risk. Sometimes that risk may seem unwarranted, but it’s not your decision. As long as everyone understands what risk they’re accepting, you have to do your best to accept it and minimize the potential damage .
Proposing a Course of Action
By pulling all of this together, you can build an entire presentation on a course of action to deal with risk issues. Perhaps it is the launch of the new ISMS or maybe it’s a response to failing audit. Whatever it is, you need to sell to executive management a plan and a budget for security. How do you use all of these techniques cohesively?
First, lay out the narrative of your presentation. When I say narrative, I am being deliberate. Present as if you’re telling a story. There are many ways to go about this. One is to begin with the current aspiration. You paint the vision of where you want things to be and how everything is going to be fantastic in this new, beautiful, secure world where all of your customers and regulators love you. New ventures and business processes can be spun up free of worry from hackers and auditors. Life is good. We just have a few obstacles that we need to get over, which are …. Then you lay out your plan and budget, citing milestones and what they’ll bring to the organization at each step of the way.
If you have the time, it’s a good idea to brief the key audience members (including your boss) ahead of the meeting. The goal of this to uncover potential objections and put participants at ease. Consider how the project lead for the mobile banking project would feel if you gave this presentation cold about how the software is full of security vulnerabilities. You don’t want him to feel ambushed, which could put him on the defensive and close his mind to your suggestions. A briefing ahead of time (sometimes called a “pre-wire”) can open the door to compromise and collaboration.
Sample Presentation on a Mobile Banking Project
I start with a slide like the one shown in Figure 8-2, which discusses the project and reminds everyone about the timeline and what’s at stake. At this point, everyone can also review the virtues of the project and the benefits that the organization will receive from pursuing it. This starts the presentation on a positive note and shows that you are all on the same side. It’s likely that everyone else is aware of this information, but I’m just setting the tone.
Figure 8-2. First slide: Why are we here?
Now that the introductions are over, let’s get right to the problem, as shown in Figure 8-3. The slide doesn’t waste executive’s time or try to hide the bad news. I include details here because I don’t want to appear flippant or hysterical about risk. These are the facts: our company’s mobile security product has some serious security problems. (When presenting, I may not chose to read aloud all (or any) of the particular details on the slide.) The slide includes a link to the actual report because this information may make someone in the room look bad. For example, in this case, the code has security vulnerabilities in it. If the VP of Development was in the room, I want to be able to give him a chance to check the results himself. Also, I want others to be able to get to the gory details if they want it.
Figure 8-3. Showing the details of the security test
In the next slide, shown in Figure 8-4, I analyze the report. The company paid a lot of money to have the security analysis done. I’m going to show that the report was used strategically. This slide shows the conclusion of the report: our mobile project developers aren’t capable of producing secure code. Notice how I frame this as a quality issue, not a security issue. This ties the problem back to customer satisfaction, not just the security geeks crying, “Hacker!” I also drop the big bomb, if it hasn’t already dawned on everyone in the room: we are about to release a product into beta test that has huge security problems. And the methods used to expose these problems are associated with one of the most common frameworks for assessing web security risk, not some obscure super-hacker tool. This means that if we publish as-is, every script kiddie with an Internet link will know about these problems as well. If we stop to fix them, however, the whole project will be delayed. No one in that room is going to want to delay the project. No doubt, sales and marketing has already promised the delivery of a mobile product by this date. We’re in a tight spot.
Figure 8-4. Analyzing the analysis
Now that I’ve dropped the bad news, I’d better have a good story on how to get the company out of this jam. In Figure 8-5, I lay out some short-term and long-term fixes, summarizing the effort and effect.
Figure 8-5. Introducing the solutions
In Figure 8-6, I jump to the first big decision: pay some money to meet the deadline, or push out an insecure and weak product. Short and sweet. Obviously, I want the problem fixed, but it’s not my call, and I do not have $32K in my own budget to fix things. This is a critical risk acceptance question.
Figure 8-6. Penultimate slide: solving the immediate crisis
Never let a good crisis go to waste. In Figure 8-7, I’ll also make sure that this never happens again by improving software quality with both training and security feedback in the development process. Both are two new controls to raise the security strength of all the development work.
Figure 8-7. Final slide, deciding future course of action
I’ve left out the suggestion to add security analysis to the design process, as there isn’t any monetary spending associated with that. It is more likely a negotiation between the security team and development team on how this would work. The actual slides aren’t as important as the brevity (five slides straight to the point) and the consideration of the audience’s perspective.