Looking at the latest QSA list from PCI (https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf) shows Verizon/Cybertrust to be in a number of possible QSA violations and failure to comply with a number of applicable QSA Validation Requirements. We've all known for sometime that the larger scale breaches (Hanniford, TJX, and others) have occurred under the watch of Verizon/Cybertrust. While I don't think the blame solely should be placed on them..They are still under an obvious review that should have been done a long long time ago from the PCI Counil. But in mentioning that, solely relying off of a compliance standard to secure you is about as effective as getting some magic snake oil. It's still a start, its the most technical compliance standard out there, but is still a compliance standard, not an information security program.
I do think this is a rude awakening for companies that are maintaining QSA's and don't perform quality work and perform the audits to the fullest extent of what the standard requires. I really do hope that companies will start working with their customers instead of rubber stamping because they send junior consultants or lack the expertise in order to complete the entire requirements list.
This should also keep several information security professionals up at night knowing that they might be as compliant as they originally had anticipated.
One thing that has totally upset me with the entire PCI process is once the breach occurs, guess who comes in to investigate? Oh would you be surprised if Verizon/Cybertrust comes back in to see how the breach happens? Does that seem completely crazy to anyone else but me?
Read more!
Friday, July 10, 2009
Friday, June 26, 2009
IPhone 3g S Enterprise Ready?
With the latest release of Apple's iPhone, the question arises to most IT savvy individuals: Is it ready for our enterprise?
There are a slew of enhancements that Apple has specifically focused on in order to attract the attention of the private sector. Most people don't know that the new iPhone Configuration Utility 2.0 allows a laundry list of configurations that enhances the overall security and control through policy. While these features are a great start, they still don't match up to Blackberry's configuration overall. Most specifically the BES Server policy management and configurable options.
Some of the features out there that iPhone does support is:
Password complexity
Remote Wipe
Hardware based encryption
VPN Access
Wireless Security Policies
and much more.
Overall, do I think the iPhone is enterprise ready yet? Most people say no. I would say why not. If you can enforce security policy on the device, ensure that the information is encrypted, and protect your mobile information in a centralized manner... Then whats the big quarrel? Is it as good as Blackberry? No. But it IS manageable if you decide to move forward with it.
Some links:
http://www.apple.com/support/iphone/enterprise/
http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
http://support.apple.com/downloads/iPhone_Configuration_Utility_2_0_for_Mac_OS_X
http://support.apple.com/downloads/iPhone_Configuration_Utility_2_0_for_Windows
Read more!
There are a slew of enhancements that Apple has specifically focused on in order to attract the attention of the private sector. Most people don't know that the new iPhone Configuration Utility 2.0 allows a laundry list of configurations that enhances the overall security and control through policy. While these features are a great start, they still don't match up to Blackberry's configuration overall. Most specifically the BES Server policy management and configurable options.
Some of the features out there that iPhone does support is:
Password complexity
Remote Wipe
Hardware based encryption
VPN Access
Wireless Security Policies
and much more.
Overall, do I think the iPhone is enterprise ready yet? Most people say no. I would say why not. If you can enforce security policy on the device, ensure that the information is encrypted, and protect your mobile information in a centralized manner... Then whats the big quarrel? Is it as good as Blackberry? No. But it IS manageable if you decide to move forward with it.
Some links:
http://www.apple.com/support/iphone/enterprise/
http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
http://support.apple.com/downloads/iPhone_Configuration_Utility_2_0_for_Mac_OS_X
http://support.apple.com/downloads/iPhone_Configuration_Utility_2_0_for_Windows
Read more!
Thursday, June 18, 2009
Check, Please!
One of the most intriguing stories in the security world today is the lawsuit Merrick v. SAVVIS in which Merrick stipulates that SAVVIS is liable for lack of diligence on an audit of CardSystems, on which Merrick relied. This groundbreaking lawsuit could change the liability landscape, allowing assessors to be sued by indirect third parties. Prior to the more formal PCI DSS program, there were many suspicions of rubber stamp audits occurring. But even today, we see organizations pushing for the cheapest audit they can do and still get the passing “check” mark. It’s this minimum approach to security we’ve often called “malicious compliance” that leads to a lack of quality and a greater risk of breach.
Just for some more background, SAVVIS had certified CardSystems Solutions as compliant under the VISA CISP program (predecessor to PCI DSS). During a breach of CardSystems, approximately 40 million cardholder data records were compromised. At that time, this was one of the biggest breaches recorded. The forensics investigation concluded that the CardSystems firewall was not compliant and that records were not being encrypted as they should be. The big debate at this point will be to determine if SAVVIS did enough due diligence at the time or if CardSystems possibly withheld any information from the auditor.
I think that last sentence is really what irks me about the relationship between an auditor and an organization. I completely understand and agree for the need of ethical independence between both parties. But I am frustrated when it creates such a wall and lack of collaboration that the auditor just becomes someone to fill in check boxes. Then the organization takes an adversarial approach in which they ‘speak only when spoken to’ and hope the auditor doesn’t uncover the dirty little secrets of what isn’t working. It’s when something isn’t working right that a breach occurs.
So when looking for an auditor, I think it’s important that organizations make a conscious, formal decision on what they are looking for. It’s the old Chinese proverb, “Be careful what you wish for since you might just get it”. If it’s a check mark approach, then understand that may be all you are getting. You aren’t getting a consultant or an advisor. On the other hand, if you are looking for a auditor who isn’t just working off a checklist but is truly interested in your organization’s risk, then you can end up with a partner that can provide a whole lot of value, not just for compliance but also for security, since the two aren’t the same.
I guess the whole point of this exercise is to step back and take a look at your organization’s approach to the quality of the security program. The most common approach is following the “Plan, Do, Act, Check” lifecycle. As a pure security assessment firm, we feel very strongly that there needs to be a big emphasis on the “Check” step, so much that we put it first. No matter what step you are performing, you need to do it well if you want quality improvement. Security is not a very forgiving practice as a misstep in quality can quickly lead to incidents, then the blame game, then someone’s job. That’s not to say that quality is costly. But cheap certainly is. So the next time you place an ‘order’ for an auditor, think twice when you ask for the check.
Read more!
Just for some more background, SAVVIS had certified CardSystems Solutions as compliant under the VISA CISP program (predecessor to PCI DSS). During a breach of CardSystems, approximately 40 million cardholder data records were compromised. At that time, this was one of the biggest breaches recorded. The forensics investigation concluded that the CardSystems firewall was not compliant and that records were not being encrypted as they should be. The big debate at this point will be to determine if SAVVIS did enough due diligence at the time or if CardSystems possibly withheld any information from the auditor.
I think that last sentence is really what irks me about the relationship between an auditor and an organization. I completely understand and agree for the need of ethical independence between both parties. But I am frustrated when it creates such a wall and lack of collaboration that the auditor just becomes someone to fill in check boxes. Then the organization takes an adversarial approach in which they ‘speak only when spoken to’ and hope the auditor doesn’t uncover the dirty little secrets of what isn’t working. It’s when something isn’t working right that a breach occurs.
So when looking for an auditor, I think it’s important that organizations make a conscious, formal decision on what they are looking for. It’s the old Chinese proverb, “Be careful what you wish for since you might just get it”. If it’s a check mark approach, then understand that may be all you are getting. You aren’t getting a consultant or an advisor. On the other hand, if you are looking for a auditor who isn’t just working off a checklist but is truly interested in your organization’s risk, then you can end up with a partner that can provide a whole lot of value, not just for compliance but also for security, since the two aren’t the same.
I guess the whole point of this exercise is to step back and take a look at your organization’s approach to the quality of the security program. The most common approach is following the “Plan, Do, Act, Check” lifecycle. As a pure security assessment firm, we feel very strongly that there needs to be a big emphasis on the “Check” step, so much that we put it first. No matter what step you are performing, you need to do it well if you want quality improvement. Security is not a very forgiving practice as a misstep in quality can quickly lead to incidents, then the blame game, then someone’s job. That’s not to say that quality is costly. But cheap certainly is. So the next time you place an ‘order’ for an auditor, think twice when you ask for the check.
Read more!
The Human Exploit
So you're sitting at your desk and the phone rings. "Hey this is Mark from information security. We are noticing that your computer is creating a lot of traffic out to the internet. Are you noticing that anything on your computer is out of the ordinary lately?"
What would you say? Well, in the average Social Engineering test we perform, the answer is quite honestly a, "yeah my computer is slow... can you guys finally come and fix it?"
That’s when we say, "Sure! We’d be glad to *cough* help! Go here, download this patch, and run it..." and a couple minutes later we have fully compromised a system sitting behind a firewall in a corporate environment and easily getting past the antivirus software as well.
On average, we are able to get over 70% of end users to comply with anything we want them to do in "fixing" their computer, by just dialing their number and talking to them. How would you feel knowing that your end users are freely giving their computers and data away to attackers over the phone?
So what can you do to stop it? Well, a lot actually. Depending on your budget (which these days is low for everyone) you have the option to proxy all of your outbound connections, close down your firewall, install HIPS/NIPS protection, and the list goes on.
Sure you can do a lot to MASK the problem, but when are you going to stop the problem at its source? No, I am not advocating firing everyone you work with, but I am saying that there should be policies, procedures and MOST of all, end user training to teach people about these attacks.
People are most always willing to help, lend a hand and be polite and courteous to others on the phone. In reality, this type of attack could happen to virtually any company. In fact, the larger the company is, the easier it is to exploit.
The moral of the story is that unless you have some type of training involved for employees, they are very susceptible to Social Engineering. Even these days. Next time, it just might not be SecureState on the other end of the phone, it could be someone with a malicious intent.
Read more!
What would you say? Well, in the average Social Engineering test we perform, the answer is quite honestly a, "yeah my computer is slow... can you guys finally come and fix it?"
That’s when we say, "Sure! We’d be glad to *cough* help! Go here, download this patch, and run it..." and a couple minutes later we have fully compromised a system sitting behind a firewall in a corporate environment and easily getting past the antivirus software as well.
On average, we are able to get over 70% of end users to comply with anything we want them to do in "fixing" their computer, by just dialing their number and talking to them. How would you feel knowing that your end users are freely giving their computers and data away to attackers over the phone?
So what can you do to stop it? Well, a lot actually. Depending on your budget (which these days is low for everyone) you have the option to proxy all of your outbound connections, close down your firewall, install HIPS/NIPS protection, and the list goes on.
Sure you can do a lot to MASK the problem, but when are you going to stop the problem at its source? No, I am not advocating firing everyone you work with, but I am saying that there should be policies, procedures and MOST of all, end user training to teach people about these attacks.
People are most always willing to help, lend a hand and be polite and courteous to others on the phone. In reality, this type of attack could happen to virtually any company. In fact, the larger the company is, the easier it is to exploit.
The moral of the story is that unless you have some type of training involved for employees, they are very susceptible to Social Engineering. Even these days. Next time, it just might not be SecureState on the other end of the phone, it could be someone with a malicious intent.
Read more!
Thursday, May 28, 2009
Identity Theft: Duty of Care to a Non-Customer
Identity theft is big business, but it also makes finding the perpetrator of a crime that more difficult. Financial and fraud investigators need to look at more then just the raw data they need to get the whole picture and story before jumping the gun. As an example, the following linked article demonstrates how being a little to quick to identify the frauster lead to the wrong person. >Identity Theft: Stutzman on a Bank's Duty of Care to a Non-Customer: It just goes to show that a what appears to be a smoking gun, isn't always the truth. Our Forensic Technology Team understands this and helps you work through these investigations methodically and with due care.
Read more!
Read more!
Wednesday, May 27, 2009
Core Network Security: A Seldom Used Bag-O-Tricks
Walk into 9 out of 10 organizations, ask them what security controls they have built INTO the network and you'll get responses like:
"We have 800 VLANs."
"We turn off ports in conference rooms."
"Who are you, and how did you get in my office?"
It really doesn't matter what core network vendor you've chosen (Cisco, Brocade, Juniper). You can drink any Kool-Aid you want and still have an arsenal of great core network security features or techniques at your disposal. These include: Dynamic ARP Inspection, DHCP Snooping, Identity Based Network Services (or any other name you want to give an 802.1x + Certificate Authority + RADIUS solution), Infrastructure Protection Access-Lists (iACLs), Router Neighbor Authentication, etc. The list is very long, most have been around for years, and many times we see NONE of them in place at organizations big or small.
Why not? Are they that hard to implement? Not really. They require planning, a critiqued design, and a phased implementation.
We forget that the network CONTROLS TRAFFIC. If you can stop malicious traffic through the system that is controlling the transport of data, you've leveraged a powerful system that most organizations naively think should only provide speed and performance. We also forget that the network can be sliced and diced for a thousand different purposes; when was the last time you had a VLAN design discussion that was solely focused on grouping systems based off risk and criticality to the business? Probably never, unless you're currently working on PCI network segmentation.
Ask these questions the next time you're in a network design meeting:
- How are we going to prevent unauthorized access to the network? Better yet, who's authorized and who's NOT authorized?
- How are we going to protect our internal core network from attack; as in, taking over specific networking services or performing covert man-in-the-middle attacks? (Hint: go play with Yersinia)
- How do we stop someone from plugging in a rogue DHCP server?
- How will we protect one VLAN from another? (They don't form shields around themselves, promise!)
- How will we protect our network from reconnaisance? (Someone sitting on your network, passively mapping everything!)
- How will we SECURELY and STRATEGICALLY manage our network devices? (Think: Out-of-Band, management ACL's, secure protocols, SNMP restrictions)
Even though the following links are from Cisco, you can apply most of the techniques across any major core networking vendor (sorry Netgear). Have a look...you'll find that most of the options found within aren't even discussed or mentioned by Sales Engineers or Professional Service firms that are looking to help you implement a network design. Demand it from them! Or better yet, design it yourself and learn a lot.
Cisco's SAFE Blueprint (Updated recently!)
www.cisco.com/go/safe
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/SAFE_rg.html
Dynamic ARP Inspection (DAI)
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html
DHCP Snooping
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/snoodhcp.html
Identity Based Networking Services (IBNS)
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/Whitepaper_c11-532065.html
Read more!
"We have 800 VLANs."
"We turn off ports in conference rooms."
"Who are you, and how did you get in my office?"
It really doesn't matter what core network vendor you've chosen (Cisco, Brocade, Juniper). You can drink any Kool-Aid you want and still have an arsenal of great core network security features or techniques at your disposal. These include: Dynamic ARP Inspection, DHCP Snooping, Identity Based Network Services (or any other name you want to give an 802.1x + Certificate Authority + RADIUS solution), Infrastructure Protection Access-Lists (iACLs), Router Neighbor Authentication, etc. The list is very long, most have been around for years, and many times we see NONE of them in place at organizations big or small.
Why not? Are they that hard to implement? Not really. They require planning, a critiqued design, and a phased implementation.
We forget that the network CONTROLS TRAFFIC. If you can stop malicious traffic through the system that is controlling the transport of data, you've leveraged a powerful system that most organizations naively think should only provide speed and performance. We also forget that the network can be sliced and diced for a thousand different purposes; when was the last time you had a VLAN design discussion that was solely focused on grouping systems based off risk and criticality to the business? Probably never, unless you're currently working on PCI network segmentation.
Ask these questions the next time you're in a network design meeting:
- How are we going to prevent unauthorized access to the network? Better yet, who's authorized and who's NOT authorized?
- How are we going to protect our internal core network from attack; as in, taking over specific networking services or performing covert man-in-the-middle attacks? (Hint: go play with Yersinia)
- How do we stop someone from plugging in a rogue DHCP server?
- How will we protect one VLAN from another? (They don't form shields around themselves, promise!)
- How will we protect our network from reconnaisance? (Someone sitting on your network, passively mapping everything!)
- How will we SECURELY and STRATEGICALLY manage our network devices? (Think: Out-of-Band, management ACL's, secure protocols, SNMP restrictions)
Even though the following links are from Cisco, you can apply most of the techniques across any major core networking vendor (sorry Netgear). Have a look...you'll find that most of the options found within aren't even discussed or mentioned by Sales Engineers or Professional Service firms that are looking to help you implement a network design. Demand it from them! Or better yet, design it yourself and learn a lot.
Cisco's SAFE Blueprint (Updated recently!)
www.cisco.com/go/safe
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/SAFE_rg.html
Dynamic ARP Inspection (DAI)
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dynarp.html
DHCP Snooping
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/snoodhcp.html
Identity Based Networking Services (IBNS)
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/Whitepaper_c11-532065.html
Read more!
Tuesday, May 26, 2009
Defining Payment Card Industry (PCI) Attestation and Data Security Standard (DSS) Compliance
A PCI merchant is any businesses that accepts credit cards as a form of payment. A PCI service provider is any company that provides a service to merchants for any aspect for their PCI environment. For both Merchants and Service Providers it is important to understand the difference between attestation of compliance (attestation) and PCI DSS compliance (compliance).
The letter of attestation can be found at the following link: https://www.pcisecuritystandards.org/saq/index.shtml. Attestation is different from compliance... Most banks currently make a distinction between attestation and compliance and request validating documents separately. Attestation is in reference to the following sensitive data whether stored electronically or on paper: Full Magnetic Stripe Data, CAV2/CVC2/CVV2/CID, and PIN/PIN Block. All of that data must not be stored in any format after a credit card transaction has been authorized aka post-authorization. To fill out the attestation form, a company must have adequately identified where any CVV information is located. Data discoveries are a typical project that is associated with this step.
To reach compliance a company needs perform all twelve requirements listed in the latest version of the PCI DSS which can be found here: https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html. The PCI DSS includes attestation requirements and many other information security practices. To validate compliance a company must submit a Self Assessment Questionnaire (SAQ) or conduct an audit, which results in an Report on Compliance (ROC).
Review this blog if there is still confusion about a bank's letter asking for attestation and compliance with different dates and forms.
Read more!
The letter of attestation can be found at the following link: https://www.pcisecuritystandards.org/saq/index.shtml. Attestation is different from compliance... Most banks currently make a distinction between attestation and compliance and request validating documents separately. Attestation is in reference to the following sensitive data whether stored electronically or on paper: Full Magnetic Stripe Data, CAV2/CVC2/CVV2/CID, and PIN/PIN Block. All of that data must not be stored in any format after a credit card transaction has been authorized aka post-authorization. To fill out the attestation form, a company must have adequately identified where any CVV information is located. Data discoveries are a typical project that is associated with this step.
To reach compliance a company needs perform all twelve requirements listed in the latest version of the PCI DSS which can be found here: https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html. The PCI DSS includes attestation requirements and many other information security practices. To validate compliance a company must submit a Self Assessment Questionnaire (SAQ) or conduct an audit, which results in an Report on Compliance (ROC).
Review this blog if there is still confusion about a bank's letter asking for attestation and compliance with different dates and forms.
Read more!
Subscribe to:
Posts (Atom)
Posts
