Reputation Risk Q&A – Richard Levick (1 of 2)

August 5, 2009

reputation-management-as-a-balloon

This past April I had an opportunity to cross paths with a public relations business called Levick Strategic Communications (Levick) and its company leaders. A couple of things stood out to me about Levick that led up to this blog post.

1.    Reputation Risk. While I do not consider myself a public relations industry expert – I have had enough exposure to the industry to understand that Levick’s  subject matter expertise on brand and reputation risk is a significant differentiator of skill expertise compared to larger public relations shops and most of the professional consulting firms. In addition, given their location within Washington DC – you can have a high level of confidence in assuming that Levick is dealing with companies and news events that we hear, see or read about on a daily basis.

2.    Informative Blog. I really like Levick’s blog called “BulletProof”. The blog posts are informative, short, and relevant. Granted, they may not be information security or infosec risk management related – but most of the posts can be associated with the loss form we characterize as “reputation risk”.

It is truly my professional and personal pleasure to introduce to the readers of this blog, Mr. Richard Levick, the CEO of Levick Strategic Communications. Mr. Levick has agreed to answer some questions I prepared about reputation risk. The intent of this blog post is to bring some clarity to what reputation risk is and for Mr. Levick to offer some practical feedback that we as information security professionals can consume and apply in our daily activities.

Thank you Mr. Levick for agreeing to participate in this question and answer blog post.

Note: Mr. Levick’s answers to my questions were provided on July 14th, 2009. Ten questions were posed to Mr. Levick. The questions and answers will be split between this blog post and an additional post in the coming days.

1. What led you to participate in this blog post?

Richard Levick: Simply put, blogs are news. People are looking in the windshield for the day that digital media overtake traditional media when they should be looking in the rear-view mirror. Just a few weeks back, Zogby released a poll that shows the Internet has overtaken television, newspapers, and radio not only in terms of relevance; but reliability. Let me reiterate how critical that is: The Internet is where we go for truth. In a world where digital news sources are more widely read and more widely trusted, you’ve got to treat blogs with the same respect you would show The Washington Post, The New York Times, or The Wall Street Journal. Today, digital media is media.

2. What is reputation risk?

Richard Levick: Reputation risk is one of two things. It is either the ways in which internal or external forces are negatively impacting your brand right now or how they will. What are today’s risks? What are our likely future risks?

Today, companies are operating in a reputational perfect storm. First, the new President and Congress are clearly intent on regulating where they feel the past Administration and Congress have been lax. Sarbanes-Oxley represents the first half of the equation – transparency. Today, we are living through the more painful second half of the equation – accountability. Second, the explosion of digital media has created a world in which there are virtually no secrets. Speed has been redefined to moments, not news cycles. Third, the plaintiff’s bar, mommy bloggers (articulate and empowered consumers), and even regulators are a full Internet generation ahead of companies facing crisis.

Bottom line: companies must immediately stop and rethink they way they think about their brand, their reputation, risk, and crisis. The cheese has moved. What got you here won’t get you through tomorrow.

3. What are the key components of a reputation?

Richard Levick: That’s a great question – because it’s where most board members, CEOs, and corporate communications professionals most often make mistakes in crisis. Too often companies think that the key component of reputation is how they view their brand when it is actually how the brand is perceived by the company’s target audiences. You’ve got to take a Buddhist approach to reputation management; seek first to understand, and then be understood.

Too often, companies in crisis do the reverse; seeking to explain rather than focusing on what audiences want to hear – what you’re doing to solve the problems at hand, and what you’re doing to ensure that similar problems never arise again.

Let’s take the recent Washington Post crisis where they attempted to sell access. It is something other magazines in the Nation’s Capital can do because they are not the Washington Post. The Post’s reputation, their brand, is as the “investigative newspaper.” They birthed the modern age of investigative journalism with their brilliant coverage of Watergate. They can’t now be offering access to the highest bidder, no matter what the pressures of the Internet Age are. It violates their brand. So the first rule is “Understand your reputation.” It sounds so simple, but its not. GM forgot. Yahoo forgot. If you don’t understand it, you can’t protect it.

And then there is Wall Street. Too many very smart, very talented Wall Street executives and corporate communications professionals still think the problem is about communicating to their fraternity. But risk and crisis change your audience. You have to think differently about what you say, to whom, and how. We have seen time and time again that Wall Street, Detroit, and many marvelous brands are still thinking in terms of the traditional media paradigm and not the digital media paradigm. Talk about fighting the last war. So the second rule of protecting your reputation is to look forward, not backward.

4. How can reputation be impacted when there are IT security incidents?

Richard Levick: Data loss and theft is the issue du jour in the 21st Century marketplace, pitting privacy and commerce interests tet-a-tet. We all want the ease of commerce that the Internet provides, but are we willing to open up to the transparency it requires?

As a company that has handled many of the data loss cases, including, to date, the largest data loss in world history, we’ve seen time and again how reputations can be adversely impacted when the response isn’t adequate, or how they can be advanced when companies run to the light.

Companies must remember that they key issue isn’t that you’ve lost the data – stakeholders understand that they’ve traded an expectation of total privacy for the conveniences of the Digital Age. The issue is how the company behaves once a data breach is discovered. Did it demonstrate transparency by acting fast to notify the authorities and inform affected consumers of their precise exposures? Did it demonstrate accountability by addressing the problems that allowed a data loss to occur? If it hasn’t already, will it be implementing best security practices that limit the chances a data loss will ever occur again?

These are the issues at the heart of reputation management during an IT security incident because if they are handled well, they show concern for, commitment to, and action on behalf of those whose privacy may have been compromised. If they are handled poorly, brand credibility and trust suffer – and that’s a recipe for disaster in an e-commerce environment where trust trumps everything else.

5. Can reputation be measured or quantified in units of dollars?

Richard Levick: I think that is pretty tough to do. People can try, and I suspect a fluctuation in stock price can be one measure, as can value – but I think the true answer is ultimately no, and therein lies the problem. Inside and outside counsel can articulate likely exposures and potential associated costs. Investor Relations professionals can certainly identify market risks. Compliance officers can estimate the costs of non-compliance. And the list goes on. But can anyone really articulate the potential cost of loss of reputation? I think the end result is too often in a crisis very smart counselors save the arm but lose the patient.

Relatively speaking, it’s easy to quantify the legal exposure, losses in market share or stock price, or even declines in employee morale that can result from a particular corrective action during crisis. So when a CEO finds him or herself at the moment of truth, analysis paralysis usually sets in because there’s no concrete way to quantify the ways in which a particular corrective action – taken to strengthen brand reputation when it matters most – will positively impact the bottom line.

That’s why it’s so vitally important for the board to mandate courage in crisis situations. When the CEO is inundated with countless reasons not to act, he or she must have the freedom to look at all the risks at play and then decide which risks are acceptable in order to protect and preserve the brand.

I always look back to the marquee case study in crisis communications – the Tylenol tampering crisis of the early 1980s. Johnson & Johnson held two news conferences a day to keep its audience informed, without regard for the fact that each statement could potentially increase the pool of concerned stakeholders or legal liability. They took a calculated risk. They exercised courage and leadership by pulling all of their over the counter pain medications, not just Tylenol, without ever being asked to by any regulator or concern for stock price. As a result, Johnson & Johnson has enjoyed 30 years of being recognized as one of the top companies in the world and Tylenol is still the top pain-reliever on the market. What CEO wouldn’t trade that for one tough quarter?

Crises demand action. Companies shouldn’t shy away from that fact simply because reputational strength isn’t something that shows up on a balance sheet.

TO BE CONTINUED…

4 Comments | Uncategorized | Permalink
Posted by Chris Hayes

QSA Vendor Selection – Points of Consideration

May 28, 2009

Earlier this year I lead a QSA selection activity for a large PCI-related program I am the security lead for. Thanks to an email conversation this morning – with a friend who is crafting a QSA-related RFP – I want to share some points of consideration that I shared with her.

1.    Carefully craft your RFP. Know what you want to get out of the engagement. Thus, when you read the responses – you may be able to quickly separate QSAs that did not take the time to tailor their response (and thus did not understand the engagement as a whole) from those that actually read it, understand your needs and want the business. In my case, before we allowed vendors to respond – we had a huge conference call. I allowed all the vendors to ask a few questions. In interesting observation from this call was that after the first four (of 12) vendors asked questions – there were no more questions. I guess they tend to ask the same questions. In addition, I think the conference call scared off some vendors from actually responding. They realized that we understood PCI-DSS and they were not going to be able to sell a shoddy engagement.

2.    Specify your minimum experience expectations for vendor personnel that will be doing the actual work. The PCI SSC outlines minimum requirements. I tend to have higher expectations and have no problem forcing my expectations on vendors. I want a QSA assessor that has between 5-7 years of “information security” – not auditing – experience. In addition, I want someone that has a certification from the Society of Payment Security Professionals. Finally, I want a QSA assessor that has been doing PCI-related assessments / consulting for at least two years. Some QSAs will balk at these experience expectations – but again, it is my engagement and my choice and I will validate that they are meeting my experience expectations.

3.    Request Resumes. Dictate that the QSA vendor provides resumes from the pool of individuals that could be performing the work. There will always be a chance they do a bait and switch on you – that is a different problem.

4.    Interview the person(s) that the vendor foresees performing the engagement. The sales / account manager may also balk at this – which if they do – that should be a red flag. The serious QSA vendors should have no problem doing this. And guess what – if the vendor pulls a bait and switch on you after the work has been awarded– demand that you interview the replacement before the actual work begins. You need to be comfortable with the QSA assessor.

5.    Validate Estimates. Make sure that the estimates the QSA vendor provides are realistic; this is a shared responsibility between the merchant and the QSA vendor. I cannot underscore this enough. Some vendors will low-ball their estimates for the hours needed to make themselves more appealing from a cost perspective or simply to provide a less then complete assessment. Each environment is unique so assessment times will vary. Regardless have another set of eyes review the estimates to make sure they are fairly realistic. Also, double check the hours needed for documentation. I am a big proponent of having ample documentation time. However, when vendors abuse the use of templates and do not take the time to do real, comprehensive documentation – that makes me really upset. This is probably a separate blog-post topic.

6.    References. Have the QSA vendor provide references. Again, they may balk or drag their feet on this. Also, keep in mind that they will not provide references from unhappy customers. The way around this is to make sure you ask questions to the happy customers that give insight to things like timeliness, quality, business acumen, and skill sets of the QSA assessors themselves. Also, get references from clients of the QSA vendor that are in the same industry and the same merchant level as you (this should already be a requirement for in your RFP; that the QSA vendor has performed QSA-related work in your industry and at your merchant level).

7.    QSA Feedback Forms. Make it known that you fully intent to provide the PCI SSC with a QSA Feedback form after the engagement with the QSA vendor. The form can be found here and can be submitted by the QSA vendor client directly to the PCI SSC. The QSA I chose never gave me a feedback form and I am debating whether or not I want to share my feedback – that I have already shared with the vendor – with the PCI SSC directly.

8.    Be familiar with the QSA Agreements and QSA Requirements. You should expect to get responses from QSA vendors that are probably in violation of these two documents. I certainly did and guess what – those QSA vendors – yes, more then one – were removed from my consideration. You can find these documents here, here and here.

In summary, one way that the PCI SSC and QSA market can get better is by merchants better educating themselves on PCI-DSS and the QSA market. Merchants need to understand that they have resources to make sound QSA selection decisions as well feedback loops to help the PCI SSC perform some QA on the QSA vendors community as a whole.

12 Comments | Informational, PCI-DSS | Permalink
Posted by Chris Hayes

The Risk Is Right.

May 21, 2009

Of particular interest to me right now is the appropriate risk amount to report on for any given issue. Being IT folks –warning broad stroke in progress – we prefer to want “precise” numbers that are not refutable by anyone and are supported by the over-whelming amount of electronic data that we have at our disposal. However, in reality – and in the information security risk management space – we lack such data. As such, there are information security industry super-stars that discourage the idea of taking a stand on quantifying information security risk; and from my perspective – devalue the subject matter expertise (some industry folks water this down to the word “opinion”) that security professionals offer to their organization. I guess I am getting off-topic – so let’s get back to topic: appropriate risk value to report on.

Quite a few risk quantification tools and methodologies tend to produce a risk value often referred to as the “expected loss amount”. Typically, this is the product of a loss event frequency value (LEF for those FAIR-minded folks) and the average monetary loss magnitude. For most information security risk practitioners and the organizations that employ them, the expected loss amount may be the most appropriate risk value to articulate to decision makers for any given risk issue. However, an additional minute or two of analysis of your loss distribution could result in you wanting to articulate a risk amount different then the expected loss amount.

Let’s take a look at some phrases and a few examples.

Loss event frequency: The probable frequency of which we expect a loss to incur.

Average loss magnitude: This is the average (or mean) loss value from a simulation or actual loss events. For example, if I perform 1001 simulations where a value between $1 and $10 dollars is drawn– I would add up the sum of all the simulations and divide it by 1000.

Expected loss magnitude: This is the product of the loss event frequency (most often the mean LEF) and the average loss magnitude. For example, if my loss event frequency is 0.1 per year (once every ten years), and my average loss magnitude is $10,000; my expected loss magnitude would be $1000.

Remember what the median is? The median is the number that is directly in the middle of a range of numbers. For example, if we perform 1001 simulations where a value between $1000 and $20,000 could be drawn and the number in the middle (value number 501, when ordered from lowest to highest) is $10,000 – that is our median.

At this point we have what could be the first comparison in determining which risk value to report. Generally speaking, if the mean and the median are close to each other, then the data set – or loss magnitude values may not be too skewed. If the mean is a lot higher then the median, then this could be the result of large loss magnitude values that are having a significant impact on the mean – somewhat “inflating” the average loss magnitude. The same concept applies is the mean is a lot lower then the median.

In some cases, using the mean loss magnitude to calculate the expected loss magnitude is appropriate. In other cases, the median may be more appropriate because the values influencing the mean are so far out in the distribution – or tail – that it would be inappropriate to use the average loss magnitude.

Now let’s look at another example. We have a risk scenario where the average loss value (per event) is $73,400, and you expect on average, 4 loss events per year. The annual expected loss ($73,400 x 4) is $293,600. However, we are dealing with probabilities and distributions and in reality there could be one year where we only have one loss event related to this specific issue and some years where we might have 10 loss events. How do we deal with this?

I performed a small experiment to help me better understand this.
From a previous risk issue, I derived the mean and standard deviations from the simulated loss event frequency (LEF) values and loss magnitudes (LM) values. In Excel, I wrote a small VBA-macro that allows me to define some simulation parameters and reference both the LEF and LM mean and standard deviation values. For each simulation iteration, the macro generates an LEF value based off a distribution that leverages the LEF mean and standard deviation. Then for each LEF value ( I round to the nearest integer), the macro then generates a loss magnitude value for each loss event and then sums those loss magnitude values. For example, if my LEF is two, then my utility randomly generated two loss values, using a distribution that leverages the LM mean and standard deviation; then sums those two values. The simulation continues until the desired number of iterations is complete. For my small experiment, I performed a simulation consisting of 3001 iterations. You can see the LEF and LM means and standard deviations in the image below.

risk_right_1_090521

Now that we have simulated loss values, we want to visually represent them. I want to represent the values two ways.

risk_right_2_090521

This is a small scatter plot diagram with a smoothed line. In Excel we create loss magnitude bins and count the number of times each iteration’s loss magnitude sum fell into these bins. As you can see the loss magnitude values look normally distributed.

risk_right_3_090521

In this chart, I want to show the percentage of loss magnitude values in relation to the loss amounts themselves. So in this chart, my simulated loss is greater then $14,924; 99.999% of the time. However, there is roughly a 10% chance that the risk could be greater then $404,924.

So what does all of this mean? What it means is that even though our expected loss value was $293,600* – the simulation resulted in the values below:

risk_right_4_090521

The lowest simulated loss magnitude was: $14,924.
The largest simulated loss magnitude was: $620,000.
The mean (average) loss magnitude was: $308,636.
The median of the loss magnitude value was: $309,000.
There is a 20% chance (80th percentile or 1-in-5), that the loss amount could be: $380,000.
There is a 5% chance (95th percentile or 1-in-20), that the loss amount could be: $441,900.

Note: The values above would change from simulation to simulation – but not significantly assuming the input parameters (LEF and LM mean and standard deviation values) remain constant.

Note: It is important to note that the term “tail risk” is usually associated with values at the 97.5th percentile or greater, or less then 2.5% of the time. While the numbers at the 1-in-20 and various tail risk points are tempting to use: please keep in mind that these are low probability / high magnitude loss amounts. Grandstanding on these values just for the shock factor – is the equivalent of crying wolf and undermines the value we can provide to our decision makers.

Now, our decision maker is faced with a harder decision. Do I assume or mitigate the risk associated with an expected loss amount of $308,636 or does this 1-in-5 loss magnitude value of $380,000 stand out to me? While it may seem like we are dealing with a small difference between the mean and the 1-in-5 values – risk tolerance, risk thresholds, and risk management strategies vary between decision makers and organizations.

Here is the take away: as you start going down the risk quantification road keep the following in mind:

1.    There is NO absolute 100% guaranteed predictable loss value – especially from a simulated loss distribution; but you have to report something. Thus choose a tool that lets you see the points from the distribution – not just a single value.

2.    Be mindful of how you articulate risk values. A consistent theme I hear and read about on a regular basis is that risk implies uncertainty – always. You need to underscore this when articulating risk to leadership.

3.    Have the discussion with your management / decision makers as to what loss value they would prefer to see. Their feedback may highly influence the value you report.

4.    Use the right value for the right purpose. For single risk issues, expected loss amounts may be appropriate. For a loss distribution (model) that represents dozens or even hundred of risks – the 1-in-5, 1-in-10, 1-in-20 and maybe some tail risk values may be the best values to react to or budget for.

Have a great Memorial Day weekend!

* In the interest of transparency, the observant reader will notice that my mean LEF is actually 4.17. For simulation purposes, I have rounded generated loss values to the nearest integer. In a given year, you can’t have 4.17 loss events. You would either have 4 or you would have 5. However, if you take the product of 4.17 and $73,400; $306,078 – you will notice that it is within a few thousand dollars of the simulation’s mean and median values.

10 Comments | Information Security, Risk | Tagged: , , , , | Permalink
Posted by Chris Hayes

2009 Verizon Breach Report

April 27, 2009

I read through the 2009 Verizon Breach Report on 4/17 on a plane from Columbus, OH to Washington DC. Below are my thoughts regarding some of the report’s content I found to be note-worthy.

Page 10 – Insider Threat. I really appreciate how they differentiated between insiders acting alone versus insiders being used as unknowing attack vectors. All to often we hear “insider threat” and assume these individuals are all malicious. For information security risk professionals – do not be afraid to ask your leadership or general council teams if this occurs within your organization – especially given the current economic climate. While I am not one to predict, it will be interesting to see the numbers next year for this threat community.

Page 11 – Measuring Central Tendency. Yes, yes, yes (almost an herbal essences moment) – statistics being used properly. As part of a risk quantification effort I am leading, I have also observed numerous instances where skewed data made the median a much more valuable variable to react to then the mean. While on the surface it sounds boring and border-line splitting hairs – the differences between these two can have a tremendous impact on decisions related to them.

Page 12 – External Breach Sources. Let’s talk about preventive controls – IP blocking. I know, easier said then done – but it is still a tool available to us. Not 100% bullet proof – but it is another defense measure that we should not discount.

Page 29 – Target of Choice vs. Target of Opportunity. This concept of determining if you are a “target of choice” versus a “target of opportunity” can factor into “threat event frequency” – how often a threat agent attempts to attack your asset and attempt to overcome its control resistance. In addition, these considerations may also help you determine the threat capability of the attacker. For example, an attacker targeting a “target of choice” may have higher skills and more time, and different motives then an attacker that happens to stumble upon a “target of opportunity”. What type of target you are will probably vary depending on the application, company, and industry. Regardless, this is a great and effective mental exercise to perform.

Page 35 – Time Span of Breach Events. Awesome stuff in this section. From a risk perspective – this type of information can be used to analyze potential impact should a breach occur. However, the report does not correlate time span of compromise to breach size – so one should not assume that the longer a breach goes undetected the bigger the impact. Regardless, there are still reputation implications that should not be discounted. If it takes a large organization weeks or months to discover something – how does that make consumers feel about that organization? In a risk assessment, time span between “compromise to discovery” could be a valuable contributing factor to document; it will obviously vary from scenario to scenario.

Page 38 – Breach Discovery Methods. I labeled this section in my notes “the forgotten detective control”. This section has really challenged my mindset on how I think of third parties as a detective security control. Let’s face it – we don’t want third parties to be a security control – at least not the control we respond to first. We often think of security controls as those things we have direct control over. In some cases, third parties may be a more cost effective control then those security controls in our own environment. I would submit that how an organization responds to third party detection alerts is very important in the consumer’s mind. I am sure there are philosophical debates on this concept. I need to force myself consider this type of security control moving forward.

** NOTE ** A great blog I keep eyes on, regarding how companies react to “situations” is called the BulletProofBlog – by Levick Strategic Communications. Even though this blog is not security related – there are quite a few posts on reputation and the public’s perception when companies are faced with a public relations crisis. Check out their post regarding the recent Domino’s Pizza ordeal.

Overall – I thought the Verizon Business RISK Team did an outstanding job on this report. This was information sharing in the purest sense with no underlying security vendor / security product FUD.

1 Comment | Informational, Risk | Permalink
Posted by Chris Hayes

PCI Treatment

April 2, 2009

pci_hurts_090402

Once again, I am pushing the limits of decency.

Some of my co-workers have been expressing their sarcasm about my deep involvement with an internal PCI program. Why, because some of them have had to take on non PCI-related projects that typically would have fallen in my court.

One of them has been making statements about PCI and how it hurts.

Another got creative and sent me a potential PCI antidote / treatment.

My teammates are awesome!

Leave a Comment » | Informational, PCI-DSS | Permalink
Posted by Chris Hayes

Stuart King – Information Security Annoyances – Response 2

March 21, 2009

In my last post, I provided some thoughts on one of Stuart King’s Top 5 Information Security Annoyances; specifically, security awareness programs. In this post, I want to touch on Stuart’s comments regarding Risk Modeling. Here are Stuart’s thoughts:

“Many “experts” preach the importance of working through risk models. It’s a load of tosh. No matter which way you try to do it, you’ll always come out with the answer you first thought of.  You might as well use a crystal ball and read tarot cards. Nobody needs to work through a complex risk model to understand that if a retail website suffers a denial of service that it’ll have some financial consequences, or  that if the internet connection is lost that there wont be  access to the..er..Internet. I’ve got better, more constructive and practical ways to spend my day than conspiring over risk models. Much more relevant is threat modelling – understand your systems and know the business so that you can make relevant risk-based decisions.”

In November of 2008, I posted a rebuttal regarding Stuart’s dislike for my approach to risk assessments. I am still convinced that Stuart’s approach is more a vulnerability assessment rather then a risk assessment – the latter of which focuses more on frequency of loss and impact while also accounting for how “vulnerable” something is. So, it is no wonder that Stuart is down on risk modeling; if the risk assessment foundation he is using is cracked, then any risk model built on top of it is probably flawed.

So what is a risk model? It means different things to different people. But here is a general description that I like from the Inter-American Development Bank : “A mathematical, graphical or verbal description of risk for a particular environment and set of activities within that environment. Useful in Risk Assessment for consistency, training and documentation of the assessment.”

Now, modeling activities themselves can be both complex and simple. I *think* that the complexity that Stuart may be referring to is more in the context of the modeling activity versus the output, or the model itself. However, information professionals can still model risk without being have degrees in statistics, being an actuarial, or attending months of technical training.  Let me explain…

Effective does not have to be expensive or complex.

simple_model

First, I beg your pardon for the image above – as it truly does push the limits of my standards for public-facing decency – but there is a real story behind this picture (essentially a risk model). My first real IT job outside the Marine Corps was for a holding company in Washington, DC of which there were five subsidiaries (two lobbying firms, two public relations firms, and a crisis management firm). The year was 1998 and our company had just hired its first CIO, who to this day is still one of a handful of folks I consider a close friend. The picture above is a representation of what our new CIO drew to the CFO of the holding company to justify purchasing a new firewall – little explanation needed. It worked. A few weeks after he presented the risk model – we were installing a Raptor firewall and were no longer relying on a Cisco router with NAT capabilities to protect our edge.

risktical_pi_chart

The image above is referred to as a Probability / Impact (P-I) Chart. It is often generically referred to as a heat map. For every risk issue and subsequent risk assessment, there is an associated loss event frequency and expected impact – that can be plotted within a P-I chart. These are not very complex to create and are very flexible. Combine some creativity with flexibility and you can visually represent risk issues in appealing ways. The ranges can be modified to be more reflective of thresholds for your particular company. It is definitely not as crude as the CIO/Firewall image above, and it allows us to plot numerous risk points. Finally, these charts are great tools for helping to prioritize which risks to mitigate first.

annloss_curve1

Above is an annualized “expected loss” curve that was produced by a risk tool I work with on a regular basis. Most tools of this nature leverage Monte-Carlo or Latin Hypercube simulation capabilities. It took only a few minutes to plug in the variables that the simulation model needs to perform the simulation (I use the FAIR methodology). For this particular risk issue, I asked the tool to perform 1000 Monte Carlo simulation iterations. It took about 8 seconds to perform. The output of the simulation gives me the expected loss event frequency and expected loss amount – both if which could be modeled like above. However, the curve above is the annualized risk curve. The annualized risk value is achieved by multiplying the expected loss event frequency by the expected loss amount. Do this a 1000 times and you get the curve above. Again, the tool I use does this all for me – in about 8 seconds. What this curve tells me is that about 90% of the simulations resulted in expected loss amounts of less then $80,000.

In closing, please understand that there are very simple and affordable risk assessment and risk model tools available to you. Most IT security risks do not require complex risk models or tools that can take hours, days, months, or even years to build – let alone simulate. Tremendous progress has been made in the last 10-15 years that gives security practitioners like ourselves capabilities that scientists and engineers only dreamed of as recent as 20 years ago.

Let’s stop hobbling ourselves and instead empower ourselves to make as big of a positive impact as possible to our employers as well as our profession. Be creative, educate yourself, be part of the solution – not part of the problem, periodically reassess your skills. This goes for Computer Weekly and the bloggers / writers they hire as well.

2 Comments | Information Security, Risk | Tagged: , , , | Permalink
Posted by Chris Hayes

Stuart King – Information Security Annoyances – Response 1

March 19, 2009

Stuart King posted his Top 5 Information Security Annoyances a couple of days ago. Stuart and I have bantered back and forth a few times on the risk assessment and risk management topics. In his most recent post, Stuart lists five Information Security annoyances, two of which I want to respond to: “Security Awareness Programs” and “Risk Modeling”.

There are a couple of reasons why I want to respond:

1.    I believe that Stuart and ComputerWeekly are unintentionally doing a disservice to the information security profession. Stuart, by broad stroking the lack of value of security awareness programs. ComputerWeekly for allowing Stuart to broad stroke under its name.

2.    I want to give a glimpse of hope for those seasoned IT Security professionals, new IT security professionals, decisions makers questioning our value, and compliance professionals – that security awareness programs do add value – if done properly.

Regarding Stuart’s “Security Awareness Program” annoyance…

Here is what King wrote: “A whole cottage industry of consultants and websites has been built up around the perceived need to educate company employees about information security. It’s all a waste of time and money. Certain individuals will point to a reduction in the number of lost laptops as a measure of success, or an increase in the number of people who can correctly click “a). All policies are on the Intranet” in a multiple choice questionnaire. The fact is that security awareness programs are received within the organization with about as much enthusiasm as a plate of sick. The key to good information security is strong governance, good communication and well managed, decent processes.  Security awareness programs sap energy and resources, and have little positive effect. Drop them.”

Where to begin? Instead of nit-picking line-by-line, let’s try to describe what a good security awareness program looks like (not in order of importance) – and I am probably missing some other attributes.

1.    Accessible
2.    Relevant
3.    Incentives
4.    Interactive
5.    Compliments other risk management processes

In 2008, I participated in a fairly large IT security risk assessment for a large business unit. Without going into details, the primary product distribution capability for this business unit leverages independent contractors and their employees across the United States (around 25,000). There were a few risk issues that we deemed necessary to document and one of the mitigation plans was to create a security awareness program. On a side note, the team responsible for this program did an absolute bang-up job and I am really proud of their hard work.

How is a security awareness program a “security control” and thus a mitigation option? In other posts, I have mentioned that there are generally three types of security controls: preventive, detective, and response. A security awareness program can span all three of these security controls.

Preventive: If the program educates the target audience and it changes a behavior that results in less security incidents and subsequently less loss – at a reasonable cost; it has value.

Detective: Security awareness programs may not result in being able to prevent all bad things from occurring, but it may allow the target audience to better know when to alert security or leadership that something bad is occurring.

Response: I have witnessed numerous instances where information security was proactively engaged to address a security issue because of awareness programs. Had some of these issues or incidents gone unreported, it could have resulted in long periods of data loss or reckless behavior -that would have cost the company more money to address at a later time.

Back to what a good security awareness program looks like…

Accessible. The program needs to be accessible to the target audience. Whether it is a web-based application, a distributed CD, or an in-person meeting you have to make it accessible. If it is not accessible, then people will not know how to participate, let alone embrace it.

Relevant. Security awareness programs need to be relevant. Relevant thus implies that it will have to change from time to time to keep in step with the risk landscape. Does that mean that solid security principles no longer get addressed in the program? No, what it means is that the program needs to address the biggest threats we are faced with today and how our security controls / programs we have in place address those threats.

Incentives. This is easier said then done. For the program I mentioned above, the team that put it together was able to get the security awareness program certified by a few states in the US for official “continuing education” credits (specific to a certain industry / licensing requirements). Thus, the security awareness program not only educates the target audience, but it also helps them fulfill continuing education requirements to maintain their licenses to distribute our product in the state(s) they operate within. With a little imagination, you can probably create your own incentives as part of your security awareness program.

Interactive. This is a no-brainer. Make it interesting to the target audience. There are so many learning styles and it is hard to accommodate all of them. However, if we want people to take time out of their busy schedules to participate in our program – it cannot be boring.

Compliments other risk management processes. The security awareness program needs to be leveraged across other risk management processes. For example, for a program that is focusing more on data protection- can I correlate places where data loss is occurring to individuals in those areas that have or have not participated in the security awareness program? Of course, there is also the compliance angle. For those US readers, there are many US Government, State, and industry regulations that mandate “security awareness programs”, so for someone to simply recommend that you “drop them”, is irrational.

One final point I would make is cost. An effective security awareness program does not have to cost a lot of money. The security awareness program I mentioned above cost around US $0.50 (includes both hard and soft dollars) per individual in the target audience. For less then 50 cents a person we are able to educate them and fully expect a decrease in certain types of loss events. Our consumers benefit, our independent contractors benefit, and our company benefits.

In my next post, I will respond to Stuart’s Risk Modeling annoyance.

3 Comments | Information Security | Tagged: , , | Permalink
Posted by Chris Hayes

Application Security Risk Assessments

March 16, 2009

I have so many topics and thoughts that I want to communicate on this blog. I could write for days on PCI-DSS; especially an exercise I recently lead to select a QSA for a professional services consulting engagement; not to be confused with a PCI-DSS compliance assessment. I have a load of thoughts about the current book I am reading by David Vose titled “Risk Analysis, A Quantitative Guide”. I still have not transferred my notes regarding Securosis’ “Business Justification for Data Security” paper to a blog post. BTW, Rich Mogull – congrats on the new born!

For this post I want to share some information about a professional development project I lead back in 2007 and 2008 for my employer that bridges application security and risk assessments.

When I first started working for my employer, I knew that I was going to be performing risk assessments. However, I thought most of my risk assessments were going to be more in the area of networking information security and data information security. Within a year of starting the job – I knew that application security and risk assessments were going to be a significant part of my job. So, because I was weak in the application security discipline, I added application security to my personal development plan in 2007; it is still there today. My quest for learning more about application security resulted in co-developing an application security assessment methodology for our employer as well as lead me to reviving the Columbus, OH OWASP Chapter.

The problem I faced in 2007 was that I was being assigned to more and more complex application development projects. Because I was not very skilled in the application security discipline, I could not perform effective risk assessments. For example, I struggled identifying meaningful vulnerabilities let alone being able to validate vulnerabilities without wasting another team member’s time. So, my manager allowed me and two higher skilled individuals on our team to sit down and document how they approach an application security risk assessment. Eventually, one of the two individuals left our company and went to go work for Amazon as one of their head application security professionals. The vacancy was short. We added another person to our team who came up through the application development ranks and provided the extra spark we needed to get the methodology from a straw-man to a usable product in late 2008.

Disclaimer 1: Our application security assessment methodology is not limited to just web applications. In large and/or complex environments – you do not have the luxury of dealing with just web platforms and simple backend databases. You will most likely be dealing with multiple applications, use cases, and business processes that span numerous technologies, languages and protocols.

There six high level concepts to this methodology. The first three concepts are straightforward and usually give you 80% of the information you need to facilitate a risk assessment. The last three concepts usually require more time and understanding. You will also notice how they all build upon one another – which should also reduce the number of information gathering activities. Let’s jump into them.

1. Information classification.
The very first thing we want to understand is what type of information is handled or exposed as part of this development effort. Is it public information or confidential information? Are we sharing information with a new application? Are we sharing information with an external business partner? Does this development effort allow for data to be modified? What is the business purpose of this information?

Let’s face it, for most vulnerabilities that can be exploited AND result in data loss – if we do not understand the value of the information – we cannot appropriately communicate the severity of the exposure (or lack thereof) to our business partners. I want to give a quick plug to the Securosis team on the information value concept. They dedicate a portion of their “Business Justification” white paper to information value and it is worth reading if you need a refresher on or are new to information value.

2. Use Cases.
The next area we want to have visibility into is use cases. Understanding the use cases is probably one of the most efficient ways to learn information about an application. Properly documented use cases should let you know who is using the application, what other applications the application under review interfaces with, data flow, business rules, and a ton of other information.

Do not underestimate the value of use cases. BTW, documented use cases should be a requirement within any project delivery methodology. If your organization does not have a defined project delivery methodology – you can find use case templates on the Internet. Make it one of *your* requirements in order to complete an application security assessment. Not only will you benefit – but more then likely the whole project team will benefit from it as well.

3. Application Architecture.
Application architecture can mean different things to different people to different organizations. To keep this high level – let’s stick with application architecture in the context of web applications and interfaces with other applications. If a web application: is the architecture appropriately tiered? Does the architecture result in the application interfacing with other applications or business partners where it could be inheriting risk of those applications? Does the data being handled have special architecture security requirements? There are dozens of other questions but you should get the point.

A simple example of where application architecture comes into play is PCI-DSS. In appendix F of the PCI-DSS requirements – you will notice that one of the first questions the QSA (auditor) is asked is whether scope of the assessment can be reduced due to network segmentation. I am sure you can think of some other business processes or information types where security requirements can significantly impact the application architecture (or find vulnerabilities within the existing application architecture).

4. Access management.
Simply put, how do we control access to the application and how does this application interface with other applications, databases, or services. I consider this security 101 stuff – but in an application security context. Also, even in companies with well defined security policies and mature security practices – do not think for even a quarter of a second that there is not someone trying to do more with less when it comes to shared IDs and passwords or using unauthorized user repositories for access management (local DB versus LDAP integration).

An additional thought that I would share on this topic is not taking for granted excessive rights a user might have for public data. An example that one of the co-developers of our methodology uses is that of an intranet application that allows all employees to view the cafeteria menu. This is essentially public information. However, we still need to have more stringent controls around who can modify the data lest we find ourselves reading that the main lunch course is “possum belly and grits” instead of a “muffaletta sandwich with olive salad”.

5. Code implementation.
This is a huge and important concept of which I can only scratch the surface as part of this blog post. For the OWASP folks out there – you know what this is. Do we have sound code development practices? Do we have security controls at all tiers of the application; including the most forgotten tier – the client tier? Do I have special data security requirements that need to be accounted for in my application code?

While this concept may be the most complex it is also a concept that separates the wheat from the chaff amongst application security professionals, information security professionals as well as security-minded developers. If you ask a self-proclaimed security professional or a self-proclaimed security-minded application developer what input validation or buffer overflows are and they miss the answer by a mile – red flag. Inspecting code and validating vulnerabilities is another topic worth mentioning in this post. I have been in the position where I ran a web application vulnerability scanner and raised red flags on SQL injection findings to the development team; only to find out that it was a false positive. I was personally embarrassed and professionally I felt that it made our profession look bad. It was a valuable lesson learned and continues to be something I reflect on from time to time to make sure my personal development plans are hitting the mark.

6. Operational Plans.
This concept is more about how an application team manages their application. Whether more in the context of the software development life cycle (SDLC) or day-to day operations – there are often points of vulnerability in this area that get overlooked. Some questions related to this concept may be: How do I control my source code, let alone access to it? Do I have adequate and appropriate logging within the application? Am I logging information I should not be? How do I provision and de-provision access to the application? How is production support handled?

It is too easy to forget about the day-to-day operations of an application especially for projects where the application is brand new. The way I look at it, this is the perfect time to make sure the requirements are established up front as well as implemented – versus being reactive post implementation. For existing applications – especially application that never received a security review or a recent security review – here is the reality: The threat landscape and regulatory landscape is ever changing. Just because there were not security requirements five years ago or even 20+ years ago (yes, we have an application that old) does not mean security controls should not be implemented today.

So there you have it folks, a very general approach to performing an application security assessment. Of course, once you flush out some risk issues, you can assess them for risk using your favorite risk assessment methodology.

If this application security assessment methodology appeals to you – let me know. Better yet – if what general information I have shared is lacking – please let me know. Either point me in the direction of a better methodology or give me some insight to help make it better. One final note, I do have intentions of getting my employer’s permission to give a more detailed presentation of our application security assessment methodology at a future Columbus, OH OWASP Chapter meeting.

Thanks for reading my blog – have an awesome day!

9 Comments | Application Security | Tagged: , , , , | Permalink
Posted by Chris Hayes

Scatterbrain Post

February 17, 2009

The last few weeks have been crazy. I am working on a post (as time allows) to provide some thoughts on the Securosis “The Business Justification for Data Security” white paper. In the mean time, below are some thoughts I wanted to share. Off you go…

1. M&A Due Diligence. Back in the late 90s I worked at a lobbying / public relations firm in DC. I worked for a holding company of which there were five or six subsidiaries. When the holding company was purchased in either or 1999 / 2000 – there was very little IT diligence performed in the areas of licensing. Sound like a no-brainer. The same due diligence applies today but is compounded in some cases by regulatory compliance and PCI-DSS compliance. A few things to look at when looking at a merchant and their PCI compliance:

a. Are they compliant?
b. What is their SAQ anniversary date?
c. What level merchant were they at the time of being considered compliant?
d. What level merchant are they now?
e. In cases where merchant level may have changed between SAQs, what is the most recent SAQ date?
f. If they are not compliant, what milestones have they committed to their processor for becoming compliant?
g. If they are not compliant, what is the estimated cost to become compliant?

In cases where a merchant is purchasing another merchant, you need to know the answers to the above questions. You also need to understand how the processors will view your company from a merchant perspective. Understanding some of this could impact integration plans and acquisition costs.

Next…

2. More FAIR Scenarios. Kevin Riggins over at InfoSec Ramblings (and fellow SecTwit) has some FAIR related posts at his website. It is great to see others embracing FAIR as well as discussing it in such an open manner. One of the best ways of learning is teaching. Good luck with the scenarios Ken!

3. Risk Quantification and Modeling. One of my “special” projects that started in late 2008 is being continued in 2009. Quantifying risk in term of dollars is the core of the project. However, the reporting and modeling based off the data is really where the value is at. Luckily, I work for a company (within an industry) that understands risk – really, really well. Hopefully, some day I can share some details of this effort and what the outcomes will be. I am really excited about it!

Finally…

Random “Not Good” Thought. Gym buddies. Over the last several weeks I have noticed some gym buddies in the gym I workout / run in. It is very annoying. These two guys pal around like they are 10 year old best friends. They are inseparable and they are loud. I try to find the good in such a work relationship -  but not at the expense of being a distraction to others. Very annoying.

Random “Good” Thought. I am just really thankful to be employed right now. A few IT professionals I have relationships with have lost their jobs. Some have been in the financial services industry and some in professional consulting. I have neighbors who have lost their jobs as well and some have had to move out of their homes. My Grandmother lived through the great depression and I would submit that our current economic condition is nowhere near the impact felt during the Great Depression – from a human perspective. If you do some research on the Great Depression, you will find that there were some products / companies that really picked up market share during the “Great Depression”. Here is a URL that sheds light on this. In a few years, what will be something that defines this recession from a consumer product standpoint? Regardless, if you are reading this – you have a lot to be thankful for.

Leave a Comment » | Informational, PCI-DSS, Risk | Permalink
Posted by Chris Hayes

PCI-DSS Is Not About “Security by Obscurity”

January 24, 2009

cio_priceless_scty

Image copied from CSOnline article related to securing “pricelessness”.

Alex Hutton over at Risk Management Insight recently blogged about PCI-DSS being “…security through obscurity on a grand, grand scale.” I have a professional relationship with Alex and I know he enjoys blog bantering, so here goes.

Obscurity. I take issue with the word obscurity. Yes, it may sound like I am splitting hairs and Alex’s use of the word can probably be justified via Merriam-Webster. However, when I usually hear the phrase “security through obscurity” – it is usually in a negative context with the following attributes:

1.    The asset being protected is usually not known about outside the company.
2.    There are usually no (or effective) security controls applied to the asset to begin with.

Let’s start with #1. The bad guys know merchants and processors have access to and *possibly* store payment card information. No secret there. End of story.

For #2, there are numerous “prevent controls” outlined in PCI-DSS that if implemented properly and validated to be effective, provide a high level of protection to payment card information. So, it is reasonable to assume that in most merchant / processor cases, there are some security controls in place to protect payment card information.

A better word that Alex could have used in place of obscurity is maybe “isolation”. You can find some other valuable thoughts on obscurity over at “dmiessler.com”.

Later on in Alex’s post he states “…that PCI DSS is not necessarily concerned with Detection and Response.” I agree that once you are not able to prevent you are probably in trouble with some entity – but detect and response controls can significantly reduce and in some cases minimize loss forms as well as significantly facilitate “root cause analysis” (RCA) in cases of payment card related events and or incidents (read blog post by Don C. Weber – “get some”).

I am going through an exercise right now to go through PCI-DSS and tag every requirement to the type of control it is. I am about half way through it and amazingly the percentage of “prevent controls” is not significantly higher then the percentage of detect and respond controls (may post my findings in a later post). So, Alex – I think you missed the mark on the value of “detect and response” controls and the importance of it from a PCI-DSS perspective. You know that I am not a big fan of “value-fail” QSAs, but I do know some of the QSAs check for these controls and interview actors that participate in response processes to SWAG a level of effectiveness. Unfortunately, the ultimate determination is when an event or incident occurs. I would like to think that the card carriers and acquirers take this into consideration when determining fines for merchants or processors that are deemed to be culpable in breach incidents. Maybe not.

I support the underlying principles of PCI-DSS (see paragraph on commitment, here), especially since is such a significant portion of my current job responsibilities. However, I disagree with some QSA and processor approaches to determine if a merchant is compliant or not – especially when gauging the effectiveness of controls – which complicates articulating and managing risk associated with PCI-DSS compliance.

2 Comments | Informational, PCI-DSS | Permalink
Posted by Chris Hayes

« Previous Entries
Next Entries »
Follow

Get every new post delivered to your Inbox.