Personal Risk Management

November 4, 2011

Somewhere between self-improvement, the feedback process, perception management and total quality management (TQM) is a lesson to be learned and an opportunity for introspection. I want [need] to document a few thoughts about the intersection of these concepts based off recent personal and professional experiences.

Self-Improvement. At some point while serving in the Marine Corps it became very obvious that there were three performance paths: be a bad performer and let the system make your life a living heck, be an average performer and let the system carry you along, be a stellar performer and push the system to its limits and possibly change it. I have always chosen to chase after stellar and it has worked pretty well for me over the years. However, in some professions to maintain stellar status – you have to constantly be seeking self-improvement.

Feedback. The term feedback means different things depending on the context in how it is being used. I find the act of feedback to be challenging both on the giving end as well as the receiving end – especially when it is feedback that is not complimentary. I have had both great and absolutely horrendous experiences – as an actor in both roles. The reality is that having feedback mechanisms in place whether formal or informal is critical to have – regardless of the merit of the feedback or how the feedback was communicated. More on this later when I attempt to tie all of this together.

Perception Management. Perception is reality to most people regardless of the facts. Anyone that is actively managing their career or personal life probably cares about perception. Furthermore, we probably want to be in control of how people perceive our actions, thoughts, attitudes and even mannerisms – lest it be established by others.

Total Quality Management. My current school studies are revolving around operations management. Specifically, quality improvement, TQM, Six Sigma, etc. There are concepts around TQM that can be applied to various dimensions of our lives: personal, professional, ethical, moral, giving, etc. Without going down a rabbit hole, I am convinced that quality improvement concepts allow us to construct guard rails (control limits) for the aforementioned dimensions.

So how does all of this tie together?

If you are serious about self-improvement and managing perception – you have to embrace feedback and take into consideration if you are approaching a quality limit if a feedback opportunity presents itself (me being the recipient). You may not agree with the merit of the feedback or agree with the delivery mechanism but you have to listen – just not hear – what is being communicated. This is really hard to do sometimes and how we react to the feedback experience can destroy relationships and further erode trust. When it comes to constructive criticism feedback – if someone is taking the time to give it – regardless of its validity – could this possibly be an indicator that we are approaching some of our quality limits – whether you have defined them or not?

For example, here are two commonly used rules for determining is a process is out of control:
1.    A single point outside the control limits.
2.    Obvious consistent or persistent patterns that suggest that there is something unusual about the data.

Keeping these two rules in mind, we can go through this exercise of introspection. Such an exercise requires one to put their pride on the shelf, set aside emotions, and really try to flush out the opportunity for self improvement. And, if all this can be done in a manner with a redemptive mindset – the better yet. In the end of such an exercise, there should always be one or more questions we should strive to answer:

1.    Is there something minor I can improve on? Is a slight adjustment needed to pull me back from the guard rails or better manage perception?
2.    Is there something major going on that calls for a massive adjustment? Is there really a fire that is producing all this feedback smoke?
3.    Was I a good partner in the feedback process? Did I listen? Did I have a redemptive mindset?

Hear me folks – this topic and what I have outlined is not something I consider myself to be a stellar example of. However, I do care about self-improvement, managing my perception, and adhering to quality in the execution of my responsibilities and will strive to keep in mind what I have outlined moving forward.

That’s it.

Leave a Comment » | Informational | Tagged: , | Permalink
Posted by Chris Hayes

Risktical Blog Series: SOTSOG

May 28, 2010

Recently in the information security web 2.0 circles there has been some buzz about “breaking” into the industry, what does career goodness look like, etc. This has prompted me to think about my journey to date; and I would like to write a series titled “Standing On The Shoulders Of Giants” (SOTSOG).

The first few posts in the series may have little to do with risk management since they date back to my childhood and Marine Corps days. However, it would be negligent of me not to reference some people or things dear to me from those days since it established the foundation from which I have been built upon.

For each post, I will make a point to highlight the one or two qualities from that particular “giant” that I think applies to the information risk management professional. And just in case I forget to write the following points in my posts let me take the opportunity to do it now:

1. YOU are responsible for YOUR career (period).
2. YOU cannot control EVERY aspect of YOUR career.
3. However, YOU are responsible for how YOU deal with the things YOU cannot CONTROL
4. Its OK to admit YOU don’t know something
5. The advice I give to kids going into boot camp or learning something brand new: KEEP YOUR EYES AND EARS OPEN and YOUR MOUTH SHUT!

I hope you will enjoy the series. I will try not to expose too much of the gooey center inside my crunchy shell.

Leave a Comment » | Information Security, Informational, Risk | Tagged: | Permalink
Posted by Chris Hayes

Working With External Data (Part 2 of X)

February 2, 2010

This is the second post of a series related to working with external data for analysis or modeling purposes. You can read the first post HERE or read the “cliff notes” summary below.

***

Part 1 “Cliff Notes”

1.    Know what information you are hoping to derive from the data.
2.    Methodically narrow down your data for relevant data points. More data does not guarantee better or more accurate information.
3.    Some refinement considerations include:
a.    Time frames. Limit your data set to a span of time commensurate with a minimum level of technology as well as a consistent expectation of regulatory / industry standard requirements.
b.    Good fit. Consider points related to your industry, service offering / value proposition, and loss form categories.
c.    Duplicate records. When working with multiple external data sources, keep an eye out for duplicate event records.
d.    Consistency. Be consistent in how you analyze data points.

NOTE: Collecting and right sizing external data is useful for comparing your internal loss events to external loss events, understanding what a worst-case loss could like for your company and possibly incorporating into a data set to be used for modeling purposes.

***

In this post, I want to focus on right-sizing data points in your data set commiserate with the size of your company.

1.     Determine the minimum value where right-sizing is not worth the effort. When faced with hundreds or even thousands of data points – there is going to be a “magic number” of records where the number of records lost does not warrant right sizing. The more you understand your business processes and partner with the appropriate stakeholder (business partners, marketing, legal, privacy, etc…) the easier making this determination should be. They *should* be the subject matter expert(s) on these matters and be leveraged whenever possible.

TIME-OUT. For the uber-privacy / legal folks our there, the loss of just one record is not desirable. But, we have to be reasonable and acknowledge that are thresholds where the “squirm factor” varies.

2.    Understand the type of data lost / compromised. This is really easy to overlook. Some data loss events involve just customer (consumer) data, other events may include just employee data, and some events may include both types of data. Understanding the type of data lost could prove useful in determining which right-sizing method to use.

3.    Right-sizing factors (proportions). This is where things get interesting. It also where objectivity and consistency have to be demonstrated. Whether we are performing risk assessments, right-sizing data points, or collecting information to draw conclusions from – it is important that we are as objective as possible; reducing subjectivity whenever possible. The key point I want to make here is that if used appropriately and consistently, a right-sizing exercise is more objective in nature then stating it happened to company X so it could happen to us without any analysis whatsoever. You may want to make a brief note as to why you chose a certain right-sizing factor in case you need reminded at a later point for whatever reasons. Let’s look at a few right-sizing options (keep in mind that we are building upon what we covered in the first post):

a.    # of Employees. If a data point is from a company in the same industry or has the same value proposition – using number of employees could be a good right-sizing factor. Some inferences can be made around the number of employees. Is it unreasonable that if a company half of your size loses 10,000 records and is obligated to protect data equally as well as your company, that the same event could happen to your company for 20,000 records? Using number of employees is also useful when the data point only involves confidential employee data.

b.    Revenue. Revenue could be another right-sizing factor. Maybe the data point is from a different industry where staffing types / level differ from your industry but the value proposition is related (property & casualty insurance versus health insurance).

c.    Equity. In some cases, equity can be used as a right-sizing data point. # of employees or revenue may not be appropriate or the proportions could be unrealistic. Equity could be a third option.

d.    Others. There could be some other right sizing factors depending on your industry or the problem you need to make decisions for. Just make sure that whatever that factor is, that it is generally regarded as a sound comparative measurement factor and document any assumptions. Again, I cannot underscore the need for objectivity and consistency.

NOTE: Keep an eye out for some data points that have been right-sized but the calculated value far exceeds the total number of records you have in your organization. Consider another right-sizing factor or change to the maximum amount of records you have; and of course, document. Some situations may warrant keeping the value (like a risk assessment related to merger or acquisition where the number of records you are obligated to protect now- doubles, triples, etc…). What you don’t want is someone calling you out on a data point that is not even realistic for your organization because of a simple oversight (I speak from experience).

4.    Sources of Information. In order to right-size data points – especially in the context of the factors above (employees, revenue, equity), you have to get information about the companies related to that external data point. I would submit that the information you need is available in most of the cases – it is just a matter of time and creativity.

a.    Internal information. You need to collect your own internal information for the right sizing factors before you can right-size against external data point company information. HR may be able to give you # of employees by year and hopefully there are numerous internal authoritative resources that have your revenue and equity values (if you are publically traded – this information is publically available; though you should still confer / validate with internal sources).

b.    External information. Be Creative. Yahoo business, Dun & Bradstreet, company name Google searches combined with “annual report” or “corporate filings”, company websites and Fortune 100, 500 or 1000 lists; these are stating points. Just remember to make sure you are right-sizing in the context of the same year the incident occurred in – and be consistent.

In the next post for this series, we will look at analyzing a right-sized data set to begin collecting information. For example, does the data resemble a statistical model? Does it resemble your internal data points? What if my data set has too few data points?

Leave a Comment » | Information Security, Informational, Risk | Tagged: , , | 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

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

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

Making PCI Easier – A Reality / Health Check

January 21, 2009

To start off, I must admit that while documenting thoughts for this post I could not get the song “We’re Not Gonna Take It” by Twisted Sister out of my head.

The driver for this post was a blog post by Anton Chuvakin – where he posed the big question about how PCI can be easier. I provided some thoughts to him and he welcomed some additional thoughts.

Alex Hutton over at Risk Management Insight has also opined recently about PCI, the “compliance stick” not making compliance easier, and for those responsible for something like PCI compliance efforts – taking on a more consultative, high information value, decision making approach.

And of course, this post comes a few days after a breach disclosure – involving a payment processor called Heartland Payment Systems.

This post is not about how the PCI Security Standards Council can make compliance with PCI-DSS easier to achieve. Nor is it about how QSAs or security vendors can facilitate making merchants PCI compliance efforts easier. This post is more focused on merchants or processors making PCI compliance easier for themselves. My thought process is that if merchants can make some aspects of PCI compliance easier on themselves – then there is a reduced need for relying “so much” on QSAs and less heartache around PCI-DSS in general.

So off we go….

Commitment – The information risk management folks driving PCI compliance need to be committed to it. However, this commitment needs to be rooted in something more intangible then ensuring compliance with all the PCI-DSS requirements – which are really just a means to an end. The “end” needs to be what we are committed to; protecting consumers, maintaining business operations, and reducing credit card fraud. Yep, there are some reading this that are probably rolling their eyes and may click away from this page before even getting to the end of this sentence – but c’mon – be honest with yourself – is the “end” what we are committed to or just being compliant?

Structured Approach – Some entities may have their ducks in a row and “manage” PCI compliance to the nth degree – good for them. Others entities, are pushing it along with their bellies. Some thoughts I have on a structured approach include:

1.    Do you have the equivalent of a PCI content diagram? Maybe something that visually represents interested parties in your organization. Treasury / finance, billing, application areas, IT areas, legal, etc…

2.    What are the different PCI compliance “work streams” you are managing? More then likely you have more then one work stream; regardless of your state of compliance.

3.    Are those persons responsible for managing PCI compliance properly positioned to deal with all the PCI interested parties in your organization? A few years ago I witnessed a CIO who within a few months of being in his role, promoted a handful of IT executives to titles/roles that would be equal to their business partners. The same concept applies for those managing PCI compliance – they have to be positioned to adequately deal with non-executive roadblocks, but also have access to executive stake holders to deal with executive roadblocks.

4.    Finally, managing PCI compliance should not be relegated to the new employee or the junior employee – especially if they have no previous PCI compliance management experience. There are too many business, political, and IT obstacles to deal with that require some business acumen, negotiating, informing, and project management skills – especially in big companies.

Expertise – Those managing PCI Compliance need to be the experts on PCI within the organization. Knowing the words behind the acronym is not enough.  I would argue that those responsible for PCI compliance should be familiar with all of the requirements and know what type of control it is (prevent, detect, response). You need to be able to gauge the effectiveness of the control in the context of the asset it is applied to and your environment in general. In general, there is nothing worse in my mind then a QSA finding something you should have already known or a QSA knowing more about your environment then you do.

Continuity – No, I am not talking about business continuity – but PCI compliance management continuity when people leave a company or take on new roles. There needs to be adequate documentation and there needs to be an intentional effort to make sure the knowledge transfer occurs and that it is understood. A lack of continuity can result in weeks if not months of re-gathering information with the possibility of losing valuable information along the way.

Some of these thoughts sound like no-brainers and I applaud you for making this far in the post. If I was interviewing for a PCI-specific role, being assigned to a new PCI-specific role, or assessing a company’s PCI compliance efforts – the thoughts above would form the questions I would ask. Also, just because a merchant / processor is doing all the above does not mean they will never need to reach out to QSAs or that PCI will just magically be easier. However, I do think it will provide clarity as to what needs to be done as well as allow a company to take a stronger stand on both false claims of compliance / non-compliance by interested parties.

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

Stuart King – Risk Assessment Rebuttal

November 17, 2008

Stuart King over at ComputerWeekly.com is not complementary about my recent risk assessment blog post. I am happy that Stuart reads this blog and to his credit he helped welcome me to the blogosphere a few months back.

When I first read his take on my assessment post, I have to admit that I wanted to reach towards the screen with an open hand and ask him to choke himself – but then I flashed back to work and happiness. (Yes, I was a Marine, and my idea of humor is probably a lot more different then most folks).

After reading Stuart’s post a few more times, there is a significant difference between his idea of a risk assessment and mine. Simply put, I believe in performing “risk assessments”, Stuart believes in doing a “vulnerability assessment”.

The LOW HANGING FRUIT objection. Stuart implies that the approach I use is too time consuming – especially given the length of the post. What Stuart does not put in his post is that at the end of my post I address this misconception. What he also did not state was that the assessment I posted and future assessments are meant to be training tools for those not familiar with a formal risk assessment approach; especially FAIR.

Next, objection – using a simple language that the business can understand. I agree with this comment. Most of the assessment analysis that I posted is more technical given the audience that I know reads this blog. Again though, at the end of the assessment – I provided a three sentence, business / decision maker summary.

The most important objection. Stuart states in his blog entry that his what I will call “keep it simple” risk assessment approach is:

1.    List the threats.
2.    State the level of vulnerability.
3.    List operational costs and potential revenue hits.
4.    Describe controls and options.
5.    Write up who needs to do what; keep track of time.
6.    Slap on a high, medium or low qualitative risk label.

Stuart – you have just completed a vulnerability assessment – you are crying WOLF. You are not taking into consideration “how often your asset that has a vulnerability” is getting attacked let alone how often you experience a loss because of a successful attack. Risk assessments take this into consideration.

As for the HIGH, MEDIUM, or LOW – qualitative labels may be a good starting point. But at the end of the day, they are still representative of some loss magnitude. Stick it out there and associate a cost to the risk you are trying to explain versus doing a “wet finger in the wind”, gut feeling check.

I welcome any feedback on my blog entries and I especially enjoy defending what I believe is a solid approach to a very sought after discipline within our profession.

4 Comments | Informational, Risk | Tagged: | Permalink
Posted by Chris Hayes

« Previous Entries
Follow

Get every new post delivered to your Inbox.