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!

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!

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!

Security Assessments: Cheaper Not Always Better

In today's economy, money is obviously tight. As Ken pointed out in his blog post "Economy bad… breaches go up!", companies should be spending MORE money on assessments, not cutting back in the area. With that being said, here is some insight from a penetration tester who hacks daily on some of the things I've seen on the front lines...

So your company decides it is time to have a penetration test performed...whether it is an annual pen test, an RFP that was put out, or for some other reason, that reason for performing one may vary is outside the scope of this blog post. The number one factor for *many* people on anything is budget. Money makes this world go around. The root cause of cybercrime is money. Why do criminals steal SSN's and account numbers? To obtain money in the end. Since everyone seems to be short on budget these days, choosing the least expensive security assessor is not always the best way to go. In fact, the majority of the time I've seen it to turn out poorly much of the time. Of course, there are many things that factor into it. Some of these would be which assessors were considered for the work, how many there were in the running, etc.

To put things into perspective, here are some of things to consider when looking to have an information security assessment performed:

1. [insert large popular assessor name here] gives us a discount each year, and they told us we were good.
Does bigger always mean better? No. We can go back and look at several data breaches, especially those involving PCI data to see that large/well-known assessors had signed off on the companies that were broken into as being compliant despite not having fulfilled all of the requirements of the PCI DSS.

2. I used the local ISP, they are cheap and right here in my backyard.
That's great that they are local, but they are an ISP. They provide your Internet connection, and most likely don't specialize in security. At the end of the day, do you think they could tell you more about the latest attack trends out there or MPLS and OC45's?

3. We took the low bid on our RFP, and the assessor didn't break in for the internal penetration test...
This came from a multi-billion dollar company and the RFP included extensive internal penetration testing. If the penetration testing team does not break in on the internal network, their skills are quite questionable. The internal network is usually the squishy center of the network whereas the external facing portion is usually hardened. Unless it is a network with crazy security controls in place such as some government networks or other extremely confidential networks, there will be vulnerabilities present. The success rate of the assessor for breaking in might be a good thing to ask when shopping around.

4. For our last "penetration test", the vendor asked for a domain administrator account.
Are you kidding me?! Anyone can run nessus with credentials and reformat the report to look differently. A penetration test should be treated as if it were a real attack. What does this mean? This means that externally, the only information given should be the company or organization name. We can safely assume at the very least level that is what an attacker might have. For internal penetration tests, have the penetration testing team simply plug into the network and start from there. You shouldn't always have to give them an IP address, have them test out your NAC(network access control) perhaps, or even have them do a physical pen test to attempt to physically penentrate the building and do it all as if they are a true criminal targetting the organization. Whatever the scenario is, using a domain administrator account or any other credentialed automated scan is NOT a penetration test. A "vulnerability assessment" is running automated tools to identify vulnerabilities. When performing a penetration test, running such "noisy" tools will obviously get detected. A penetration test involves manual attacks targetting specific systems that in the end, will allow for unauthorized access. Don't get me wrong, automated vulnerability scanners are great for say, checking systems for the latest patches, but a vulnerability assessment does not equal a penetration test. I see this presented on many security assessors websites, and I am in disbelief every time. Be aware of what the security assessor is proposing in their statement of work.

There are tons of assessors out there. How do you know which are the best choice? Obviously price is a major factor, and when choosing, there are other things to consider too. What all does the vendor do? Do they perform penetration tests, sell products, do implementations, manage those solutions, and even support them? Can you trust them to not have a biased or swayed opinion or report if they have a financial interest in fixing what they found, selling you new products, as well as implementation and support of them? If the vendor conducting your testing does "everything" for you, the end all be all solution provider, they probably are not. Everyone says they can do everything, however it has been shown that once you "do everything", you become a generalist, and start to lack expertise in what you used to be good at. Ask for resumes or individual expertise for assessors that will be on the assessment team performing work for you. Someone who hacks all day every day versus your local ISP is going to be a no-brainer on what the outcome will be. Your local computer shop probably advertises building PC's, wireless networks, doing security, etc. Again, you may want to question any vendor that says they can do everything, and limit your selection to vendors that only do security assessments as their specialty.

Whether you choose SecureState or another security assessor for your assessments, remember that cheaper does not always mean better.

Read more!

Best Practice for Digital Forensics

We run into some very interesting situations with our clients. Sometimes you just can't make this stuff up. We've seen clients with former employees breaking back in to system to cause havoc to conducting covert data acquisition in the middle of the night of current employees suspected of wrongdoing. Often times companies are left to balance the need to get to information and gathering that information in a manner that doesn't trample all over the effectiveness of the data.

As an example, say you are laying off a key individual in your company and they have information on their laptop that you need. One approach would be just to have your technical support team come in and copy off the data via Windows copy or use Ghost to make a copy of hard drive. These two options will get the data copied, but at what cost?

• Will you have access to deleted data? 
• What if the data collected reveals criminal behavior or behavior that warrants litigation - do you have the data collected in a manner that can be used in court?
• Have you taken the steps to be able to show a clear picture of what occured on the computer?

So what do you do to protect yourself and the company?  Here's a list of the Top Ten Best Practices to digital forensics:

1. Document everything.
   
2. Never mishandle data. [case example] 
   
3. Never work on the original data.
   
4. Never trust the custodian’s software/hardware.
5. Maintain chain-of-custody throughout the process.
6. Only use courtroom admissible and licensed tools. [see NIST CFTT]
7. Be sure to be fully trained in the use of digital forensic tools.
8. Don’t forget other devices such as PDAs, Blackberries, iPhones etc. [see Paraben]
9. Use write-blocking hardware when doing physical acquisitions. 
10. Call an expert if you can't do any of the above!

Read more!

24: Reality TV?

This following article was published in SecureState’s Winter Newsletter. With the recent story that broke regarding the international spies from Russia and China that hacked into the United States’ electrical grid (http://www.msnbc.msn.com/id/30107040/from/ET/), this story has become more relevant. It has been something that SecureState has been preaching for quite some time… CIP is not strong enough…


Fox’s TV series 24 could very well become reality TV!

The reason is not that a simple device can be used to compromise our water, energy, transportation, etc. But because the Critical Infrastructure Protection (CIP) standard is not to the level it needs to be to protect our most critical infrastructure.

The biggest problem with the CIP standard is that it may not even be possible to be CIP compliant! The biggest issue that the North American Energy Reliability Corporation (NERC) has with its CIP standard is that it does not deal with the issue of legacy systems. For NERC itself, the problem is that it will not force vendors to upgrade their systems to become compliant.

“Until vendors are forced to upgrade their products, there is not going much in the way of actual security,” says Matt Davis, Principal of Audit & Compliance at SecureState. “100% of these EMS and GMS systems that CIP deals with were designed to do one thing… and that is work!”

These systems that do not have the option of being upgraded are then pushed aside and not tested, therefore becoming exceptions to the standard. How good can a standard be if it is not testing all systems critical to the standard?

During several CIP engagements, SecureState found that most of the systems that are in scope of CIP have never been tested to the level that they needed to be. Nor could they stand up to simple tests including vulnerability scans. In fact, CIP does not even require penetration testing!!! - A test that is required by most standards including PCI.

CIP Audits

All organizations connected to the nation’s energy grid are to begin reporting their compliance and activities this January, with audits beginning January 1, 2010.

The audits are to be performed by the seven regional NERC operators scattered throughout the country. This poses the question of how strict each individual operator will audit the organizations in their region. This could cause some heat if one group realizes they got dinged on something another organization with the same system got away with. And you can bet they are going to share and compare report cards.

“You have to wonder how much these operators are going to let slide during these audits. Is the fact that there are certain systems that cannot be upgraded going to make exception the rule? We will have to wait and see,” said Matt Davis, Partner at SecureState.

CIP Importance

The importance of the CIP Standard goes far beyond any other security regulation that there is currently in place. But CIP isn’t even as tough as PCI, for example. The net result is that there is better security in restaurants than what goes into the grid.

“PCI, SOX, GLBA, HIPAA… they all have their place in protecting the United States,” said SecureState Senior Consultant Jason Leuenberger. “But if the power goes out… those standards become obsolete!”

And the importance stretches beyond just losing a modern convenience. Because a failure in the country’s energy grid, means a weakness in the country’s security!

By Matt Franko

Read more!

Let's Get Ready to PCI Rumble!

I know this is going to sound kind of sad, but I am really excited to see what's going to happen with some of the latest PCI breaches and the organization's response. In the two the biggest, latest ones we see both Hannaford and Heartland stating their case that they were both PCI compliant. To the average person, the initial response is going to be something like, "Then the PCI DSS sucks!". However, a recent statement from a VISA exec was more along the lines of "We have yet to see a company that was breached that was compliant." So how do we judge this wrestling match?

First and foremost, we need to make a clear distinction about what it means to be PCI compliant. The position being taken by the the organizations above needs clarified. What they mean is that they had successfully completed their compliance validation activities. More specifically, that means they had their audit performed and submitted it along with the ASV scans. They met their due diligence obligation.

But now we need to reconcile that with the execs position. What he was talking about is more akin to PCI Safe Harbor. That states a company is 'safe' if they are fully compliant to the PCI DSS at the time of the breach and can be demonstrated during an audit with forensics. That, my friend, ain't easy. Compliance is something you will ultimately have to defend and is not the plaque or certificate on the wall for you did once a year.

So now we need to actually do some sort of prognostication here so you get my point. I don't have all the details for either breach, so I will make some assumptions. Let's assume both of them were breached due to malware on a system. I'll also assume they had anti-malware in place. What isn't an assumption is if it's possible to bypass malware. So I am going to assume is it did get bypassed. I am not sure if we'll know how the malware got there. Did that portion of PCI fail? Not at all. It's a good requirement and they did meet it. But PCI has many layers to it as all security programs should.

If I had to guess what will the final outcome is, it will be something like this. From what we know the big problem is that the data was breached i.e. it left their network. So just how did the data get into the hands of the the evildoers? I think that's the real question. Exactly what kind of firewall rules were in place that allowed the malware sniffers in place to send the traffic out of their network? Did the processor or the registers have direct access to the internet? I sure as heck hope not. If the attackers had some live connection into those systems, that's one thing. But I would suspect there is a lack of good egress filtering and not that the malware did some crazy cool method to bounce traffic out of their network. This kind of excessive egress would likely be caused by a lack of good process to reign in the poor rules adopted through "business justification". Personally, I think the business card trumps way too often as I have seen time and time again at clients.

So who is to blame here? I think an easy, but not necessarily correct, choice is the assessor. An auditor's job is to assure formalized, good processes and perform some testing as well. It may not be possible to audit every rule of every firewall. Even so, the auditor has to be pretty strong to push back when "business justification" has been established. It means possible rumbling with their client and their bank. But yes, the auditor may not have been thorough and some rubber stamping occurred here.

Well, only time will tell if I should quit security and become a psychic. Speaking of, my money is on the VISA exec to win the match. Even if I am wrong, there is some lessons learned here. In reality, there needs to be a strong, collaborative relationship between the auditor and the organization to both agree on a defensible position in gray or soft areas of the PCI DSS. I often say you need to imagine standing at the podium and feeling confident as you describe that position to reporters and the world. And never forget, compliance does not equal security. Business justification is not a loophole. Or if it is, a lot more can slip through that hole like malware and fines.

Read more!