(ISC)2 Blog

Why iris scanning can be a biometric

Some great high-resolution shots of human irises.  The detail here shows why iris scanning can be used as a distinguishing biometric.  Of course, posting high-resolution shots of your biometrics on a Website can be a great way to compromise your biometrics ...

SABSA

Sherwood Applied Business Security Architecture (SABSA), closely related to the Zachman framework.  The SABSA site also describes a process and other functions.

Zachman model

Current (2010) model of the Zachman framework.  (At the moment, the original zifa.com site and zachmaninternational seem to be pretty badly bent.)

Zachman

The original article outlining the Zachman Framework, a business architecture model sometimes used as a breakdown model for security planning.

Newly Redesigned Cyber Security Central

Welcome to the newly redesigned Cyber Security Central.

Cyber Security Central (www.cybersecuritycentral.com) is “Your Single Source for Everything Cyber Security” and is designed to deliver valuable information relating to the Cyber Security Community.

If you would like to contribute to the site, please email admin (at) cybersecuritycentral.com.

InfoSecElmo

Not exactly a major security awareness resource, but http://twitter.com/InfoSecElmo should be on everyone's Twitter feed.  Some cute little slogans and reminders.

New SSL Inspection Solutions: Are they helping us or not?

I saw some presentations and papers about a new technology that is able to decrypts SSL traffic and sends it to existing security and network appliances on high speed networks. This technology enables existing IPS solutions to identify risks normally hidden by SSL such as regulatory compliance violations, viruses, malware, data loss, intrusion attempts, etc.
This is a very good approach to detect/block those attacks (there are reports showing a increase on attacks using SSL traffic) but I see some risks related.

• If someone uses this technology to decrypt the traffic and get the info? What are the mitigation actions in place to avoid this?
• How this technology will handle DDOS attacks? It'll be overloaded?
• What is the latency that this technology will add on the network?
• How browsers handle this "man-in-the middle" like security solution?

There are obvious advantages to adopt such technology but a careful analysis must be in place earlier the adoption to address these risks. This will be a case-by-case study and (at least I believe) that not all companies will be able to deploy such technology due to regulations or compliance.

Best Regards

PCI Onsite Assessment - Part 5

  Part Five - Selecting a QSA!

This is the fifth chapter in a series about preparing for and going through a PCI assessment;...

1.      Part One - Intro to a PCI on-site assessment & the QSA selection process
2.      Part Two - Preparation for an on-site assessment and what to do first!
3.      Part Three - Defining your scope so you know what you’re assessing
4.      Part Four - Authoring a PCI On-site Assessment RFP
5.      Part Five – Selecting a QSA to conduct an on-site PCI assessment
6.      Part Six – Preparing your Company and I.T. department for the assessment
7.      Part Seven - Important documents to have to manage your assessment

Selection; Start off by researching about 5-9 QSA firms online via forums, networking and reputation, you can find the authorized list of QSA’s here. I split my selection process into 2 phases; first one is researching and contacting 6-7 QSA’s and having high level summary conversations with them. During this stage I try to find out about their core businesses/services, how long they have been performing PCI, professionalism, how interested they are in doing business with my organization, and things of that nature.

The second phase is after I have narrowed that list to 3 that I start to try and get a in-depth understanding of their qualifications and whom I think would be the best fit for this relationship. Yes I said relationship, this is I believe the most important aspect of your decision making, this can be (especially if it’s your first) a long stressful process that has the potential to kick off dozens of very expensive remediation projects. You are going to want a QSA that not only does his job well, but can have a great working relationship with your organization to help guide and recommend remediation and compensating control options. Having a good working relationship in what can be a 6-9 month assessment for some is critical to the success of the whole thing.

Below is a summary of critical things I look for in a QSA;

1.      A good fit for a business relationship and partnership
2.      Practical application of PCI requirements and controls in real world situations
3.      Strong background and experience with payment systems
4.      Ability to get to the core intent of a requirement
5.      In-depth expertise in subject material and ability to test controls
6.      Strong technical understanding of risks and information technology

o (Not some financial audit guy turned PCI auditor)

After you have gotten your list down to 3, prepare both subject areas and specific questions to discuss, I would also recommend you get input from your engineers and managers that own your payment systems.  Next develop interview/meetings questions and weight both the questions and answers. This will help you quantify and qualify your decision, see this “QSA Selection Scoring Matrix” as a template to help you get started, but I would recommend you add and update your own questions. Understand this is a VERY VERY subject decision, it’s hard to quantify but this should help.

Prior to setting up meetings between your engineers and theirs, request the QSA give you a hard list of which team members will be dedicated to this assessment and request they be on the calls. Many QSA firms will tell you they can’t promise you who will be available when the assessment comes around, and I understand it’s hard for them to do so. But demand that both the engineers that are on the calls and are in essence the ones selling the QSA firm to you, are also be the ones that will be performing the assessment.

Don’t let them switch on you, hold them to it and/ or get it in writing, I have seen this in the past where you will have meetings between your engineers and their best experts, build a strong confidence in their ability to conduct the PCI assessment, and then after they get the contract they switch their team, taking those guys off and adding less experienced staff. Can you say bait and switch?

Now you are ready to setup meetings between some of your engineers and there’s. Remember ask the questions in your scoring matrix and score their responses. Don’t be scared to go into a few areas you know you are going to have problems in, this will not only help you assess their practical PCI expertise, but give you an idea of are they going to be a partner, or would this be a combative relationship. Also test the waters on arguing a few requirements with them as far as what they feel is the intent of the requirement, and argue a few areas you feel you may have compliance challenges, this will help you gauge where their head is.

During these meetings go over your RFP and environment make sure they are both well understood. Ask what their experience is related to your environment, applications, databases, payment systems and what background their engineers have with these systems. Have they only audited them, or have they administered these in the past as engineers, that’s an important distinction. Also ask questions about the experience of the QSA project manager that will be in charge of the assessment on their end.

Remember this is not an exact science, but with any auditor selection it’s important to try to get it right, because this could be a long relationship.

PCI Onsite Assessment - Part 4

    Part Four - Authoring your PCI on-site assessment RFP

This is the fourth chapter in a series about preparing for and going through a PCI assessment;...

1.      Part One - Intro to a PCI on-site assessment & the QSA selection process
2.      Part Two - Preparation for an on-site assessment and what to do first!
3.      Part Three - Defining your scope so you know what you’re assessing
4.      Part Four - Authoring a PCI On-site Assessment RFP
5.      Part Five – Selecting a QSA to conduct an on-site PCI assessment
6.      Part Six – Preparing your Company and I.T. department for the assessment
7.      Part Seven - Important documents to have to manage your assessment

Your RFP;  There are many critical elements to your PCI on-site assessment RFP, here are four of them;
1.    Scope,
2.    Resources,
3.    Deliverables,
4.    Schedule,
5.    Costs.

For a template to get started, See “PCI v1.2 RFP PCI Onsite Assessment (V2.0)” in the docs section of my site.

Keep in mind it is perfectly okay during the first half of the QSA selection process to update your RFP as you are learning additional relevant information, either by discovery or through interviews with the QSA firms. You should hold on to your RFP while you are researching and questioning the initial round of 5-9 QSA firms you are considering. Once you are down to 3-4 QSA’s and you feel your RFP is as good as it’s going to get, submit your RFP to the final 3-4. After which point it will get modified to accommodate questions, legal matters etc. as you move along and finally get to your final signed RFP/SOW.

Also remember the QSA SOW which will be based upon your final RFP is a legally binding contract once signed by both parties, so make sure you have everything you want in it and expect from the assessment.

1.    Scope; as mentioned in part 2, you should define your scope and perform your own “Internal payment systems and card holder data scoping project.  You should have your scope well defined prior to engaging a QSA. But for argument sake, let’s say you have not performed a scoping project and mapped out your card holder data environment. This is unfortunately normal for many organizations prior to engaging a QSA for the first time.

The QSA’s that you engage with during the initial phase of your assessing them, should be able to provide you enough guidance on how to get pretty close. Part of that help should also come from any vendors that provide solutions you may use (i.e. Micros). However keep in mind that the QSA’s will push back by saying, “We can’t really give you an accurate quote or how to scope the assessment without either being there to assess it or reviewing visio diagrams, CHD flow charts etc”. This is the classic chicken before the egg problem. But like I said earlier they should at least be able to get you close.

When you make your final selection, down to the final 1, even without a solid scope defined, they should be able to give you a soft quote. The next step is get your NDA signed with them so that you can give them visio diagrams, and other relevant detailed documentation so that you can work together to come up with a final and agreed upon scope.

2.    Resources; Make sure you define exactly what resources the QSA plans to dedicate to this engagement, don’t let them waffle on this and make sure you have a defined set of QSA’s that are dedicated to your assessment.

3.    Deliverables; Other than the obvious, a “Report on Compliance” or assistance in filling a SAQ, make sure there are no assumptions here. My favorite movie line of all time was the comment made in “Under Siege 2” (ok not a great movie) where one of the bad guys asked another whether Steven Segal was dead and did he see the body, the bad guy replied no I didn’t see the body but assumed he was dead. The lead bad replied “Assumption is the Mother of all F*up’s”. So true. Ok let’s move on shall we?

Know exactly what you want to get, and define it, for example I spell out in part of the agreement that the QSA must provide detailed guidance on areas of non-compliance. Translation, they have to work with you on remediation and/ or compensating controls options. Also make sure you list specific documents (data flow charts, compensating control docs) from the assessment you want. Do not assume all documentation they produce they will provide to you. I have heard of some sneaking QSA;s in the past requiring a merchant pay extra on top of the original fee for documents like this.

4.    Schedule; This one is maybe even harder then scoping the assessment, like in everything in I.T. its always going to take 4 times longer than you can ever justify, whether its I.T. busy putting out fires, remediation projects large and small born from area of non compliance or because it’s your first time and things came up you just didn’t know about.

Make sure you give yourself at least 6 months, regardless of merchant size and especially if it’s your first time going through an on-site assessment with a QSA. Hey if you finish 3 months ahead of time great, but if your ROC is due next week and your 3 months out before remediation project or tasks are complete, which scenario do you want to be in?, that’s what I thought. Also remember the QSA works for you, and yes they are going to have other clients but he should always try to accommodate your schedule.

Make sure you define the phases of the assessment, and the end of the assessment time-line. Refer to and define the end of the assessment time-line is that agreed upon time frame that you and the QSA make the final draft work on the ROC. This needs to be formalized on when you expect the first draft ROC from them, when you get it back to them with your changes when they get that revision back to you and so, that way you’re not confused at the end and can get your ROC to the bank in time.

5.    Cost; This of course is going to be based primarily off of the scope, that’s why I can’t say loud enough how important that is, but make sure you have in the SOW how they plan to price things if you start to go way outside the original scope, whether its fixed (expect a higher quote with this option) or fixed hourly pricing. Also if you’re a retail outlet and got stores all over the place you need to define how many (don’t forget off-site DR facilities) sites they need to visit and perform an on-site assessment. See “Infosec-rusch Travel Incidentals (2009-2010)v4.xlsx” in the docs section of my site.

PCI Onsite Assessment - Part 3

   Part Three - Defining your scope so you know what you're assessing

This is the third chapter in a series about preparing for and going through a PCI assessment;...

1.      Part One - Intro to a PCI on-site assessment & the QSA selection process
2.      Part Two - Preparation for an on-site assessment and what to do first!
3.      Part Three - Defining your scope so you know what you’re assessing
4.      Part Four - Authoring a PCI On-site Assessment RFP
5.      Part Five – Selecting a QSA to conduct an on-site PCI assessment
6.      Part Six – Preparing your Company and I.T. department for the assessment
7.      Part Seven - Important documents to have to manage your assessment

Scope; The first thing you need to start with before anything else is to make sure you know what your scope is. I know this may be hard to do prior to having the assistance from a QSA (chicken before the egg), particularly if this is your very first on-site assessment. But this is the most crucial part because this is what your entire PCI compliance program centers around.

I don’t think I need to go into all the problems and potential liability and compliance gaps you leave yourself open to if you improperly define your Card Holder Environment (CDE). Not to mention how potential wrong your RFP will be, this in return can cause the assessment to explode (can you say scope creep) and expand way beyond what you had envisioned and probably originally budgeted for . . . ooooops! . . . . . let the dominoes fall.

Start off by conducting a payment application/credit card data mapping project to properly map out your payment application environment and CHD flow. You want to do this a couple of months prior to authoring your RFP. Make sure that the payment application/data and process owners have ownership in this project (they should want to know this stuff anyway) to ensure the documentation and flow charts are as accurate as possible, don’t let them dump this project on you.

NOTE; tell them that this documentation is going to be requested by the QSA anyway.

You should also enlist the assistance of the payment application vendors (i.e. Micros, Radiant) to help you and your engineers in properly mapping these elements. Here is a list of things I recommend you discover from this project;

Let’s start with how and where you take card payments;

• Where do you take card payments, stores, kiosks, online, etc;
• What online applications take payments, are they web facing?
• Do you take any physical card payments (i.e. knuckle busters, FAX, etc.
  • (if so follow physical security, data retention and disposal requirements)
• Do you take card information over the phone and record this conversation?
  • NOTE; This recording and the systems that contain it are now in scope.

Next lets look at the network objects (as PCI calls them);

• Document applications, their versions and patch levels,
• Document the systems (servers) that they reside on,
• Document where on the network these systems are on, and what other systems they communicate with regardless of service,
• What is the classification of that systems (CHD resident, processed, connected, all the above),
• What applications reside on those systems and what other application do they talk to,

Next let’s map out our data;

• What is the state of the data, encrypted, proprietary or plain text,
• If encrypted how, what level/algorithm, is it asymmetric, symmetric, or PKI
• What devices/application have access or hold the keys to decrypt the data
• What system handles the key management
• Where is the data, where does it start, the card swiper, “Swiper No Swiping” (that’s for you daddy’s out there)
• Map the CHD as it travels through the payment application systems and ask;

How does the data move through the network;

• If you have remote stores (such as a retailer or restaurant) how are your stores connected to the corporate network, MPLS, VPN or what.
• If applicable, you should also make sure your MPLS contract has specific language in it that addresses security issues (you network admins know what I am talking about) and privacy. For more about PCI and MPLS reference this white paper.
• Find out what the state of the data is as it travels through each segment of the network and through the cloud.
• Who has the keys to the castle and what is the level of their access;
  • System administrators,
  • Database administrators,
  • Application administrators,
  • Encryption Key Administrators,
• During this process, document job roles, users and/ or persons that have bulk access to card holder data.

Note; do not get too much into the weeds during this process, the purpose of this endeavor is for scoping the assessment, not conducting one (YET).

Now wasn't that fun!