« November 2008 | Main | January 2009 »

December 31, 2008

When Not to do Forensics

The following is a guest post by Jonathan Care. Jonathan is a Sr. Consulting Manager inside the EMEA practice at VeriSign.

Why do we want to do a forensic investigation?
The goal of a forensic investigation is to establish certainty of fact in a particular situation, normally as part of an incident response. Therefore one chooses to perform a forensic examination when one needs to establish facts relating to activities performed on a computer. The scenario for forensic computing is usually around a litigation support case, for example, tracing fraud, unauthorised activity, illicit content perpetration, or other computer misuse.

Where are forensic investigative results commonly used?
Forensic computing reports are normally used as part of a court process, or an internal employee disciplinary event. Therefore one question that must be ascertained is where the case is likely to end up - if a criminal case, then forensic reports must establish certainty of fact beyond any reasonable doubt, whereas in a civil matter the forensic report must establish a balance of probablity that alleged activities did (or did not) occur. The burden of proof in a criminal matter is therefore a much higher hurdle to clear.

What kinds of businesses will use forensic computing?
Traditionally, forensic computing has been in use by the public sector law enforcement agencies, however it is now being seen as a mainstream activity as part of the ICT and corporate governance of commercial organisations. Where an organisation is operating in a regulated framework (for example, a financial services company), forensic computing can be seen as evidence of the duty of care required in loss management and fraud recovery. Typically, the use of forensic computing services depends on the risk appetite of the organisation, in addition to externally imposed regulation. For a company operating under the controls of PCI-DSS, forensic computing investigations can be seen as a best practice under principles 3,6, and 10. However it cannot be denied that undertaking a forensic computing investigation can be a timely, costly, and intensive process, although should the case end up in a court of law, then the omission of such an investigation can prove even more so!

Who is involved in a forensic computing investigation?
Forensic computing activities are best performed by specialist personnel - these can be either internal staff, or more commonly external experts. The use of external experts demonstrates impartiality that may not be accepted by an organisations internal employee. A recent case dismissed an internal IT manager as an "expert" due to concerns over impartiality and formal accreditation. Of course the use of external experts can add to costs, and the risk assessment must be made over potential losses in court vs. the costs of establishing a solid evidential base.

When to engage in a forensic investigation
As part of incident response planning, the organisation's appetite to risk should be established. Strategic and tactical planning in this area is essential - during the "heat and noise of battle" when an incident is detected, it is hard to make a balanced risk based decision that is in the best interests of the business. Scenario based planning should address:



  • Where is this case likely to go? (criminal/civil court, employee tribunal, internal disciplinary, liason with security service providers e.g. Antivirus)

  • What is the estimated financial loss? While stories such as "The Cuckoo's Egg" make interesting reading, commercial realities dictate that if the estimated financial loss is below the acceptable loss percentage, then a strategy of internal recovery - patching systems, reviewing firewall/IDS configuration, and moving on, can be appropriate. It is important to consider not only a single incident loss, but the likely annualised loss.

  • How will the case affect the organisations external reputation? Due to data protection legislation, organisations are commonly required to publically state when personal information has been disclosed as part of an incident. This can range from the "lost laptop" through to web site breaches and fraudulent insider activity. It can be argued that the engagement of external digital forensics expertise can not only have practical and immediate benefit, but can also assist in the organisations PR activitity surrounding the incident, demonstrating a concern and care for the information under their control.

  • Is the scope of the incident completely understood? In a qualitative analysis of the incident, an understanding must be gained of how much impact has occured. For example, in the "lost laptop" scenario:

  • Was the data encrypted? Bear in mind that in addition to items stored on the hard disk in a secure area such as PGP's PGPZip or Virtual Disk) that the laptop may contain useful artefacts to an attacker in the web browser cache and history, or in email storage (for example an Outlook PST or OST file). If whole disk encryption has not been deployed, then there is a non-neglible risk of additional information security breaches.


    • Were any authentication tokens (passwords, certificates, ID keys and so on) lost?
    • Is the likely suspect known? (that is, is the suspect an internal employee/subcontractor, an external partner, or an unknown attacker from elsewhere)

    • What logging and audit measures exist for affected systems?



So, where:

  • the scope of the incident is clearly bounded
  • the external impact is low
  • the loss is below the acceptable loss ceiling
  • it is certain that the case will not progress to court
then it is safe not to progress with a full forensic investigation. However, a graded response may be of benefit. For example, where employee malfeasance is clearly indicated through other channels, a full forensic investigation of the employee's personal computing equipment may not be carried out immediately, as HR have enough evidence to terminate the employee's contract of employement. However, in anticipation of a future employmet tribunal, evidential images of the affected systems can be taken, and stored against the necessity of future legal activity.

In addition, where the affected equipment involves card information in the clear, that an investigation is warranted to ascertain the business processes that caused this breach of PCI-DSS standards to occur, and that an impact analysis is highly advisable.

December 29, 2008

Using OpenSource Tools for Compliance & Security

The following is a guest post by JD Smith. JD is a Sr. Consultant inside the PCI practice at VeriSign.

PCI DSS 1.2 has several sections that require a security application to be used to satisfy a requirement. Some of these areas are file integrity monitoring, firewalls, encryption, wireless scanners, intrusion detection/intrusion prevention and anti-virus.

All of these areas have several tools available to address the specific requirement. However, what if a merchant needs to keep the budget to a bare minimum? What if there is absolutely no way a merchant is able to purchase several of these solutions straight off the shelf and pay the licensing associated with them without severely impacting the business?

Open-source solutions exist for practically every requirement identified in the DSS. What is open-source? Generally speaking, open-source is considered to be a solution for something is maintained by a community and is typically royalty free.

For instance when it comes to intrusion detection systems, there are open-source tools such as Snort that has matured over time and is known as the gold-standard for IDS. Many front-end analysis tools exist that use the Snort engine (e.g. Squil and BASE).

For merchants that must secure their wireless environments, open-source wireless scanning tools such as NetStumbler, Airsnort, and Kismet have been in the security toolbox of pen-testers for quite a while now.

Merchants who are struggling to find a powerful firewall solution while staying true to open-source should take a look at NetFilter. It runs on a Linux operating system and is able to handle as much traffic as most other expensive solutions.

Another major component of PCI DSS 1.2 is encryption. For solutions around SSL, OpenSSL is the premiere SSL/TLS encryption library. Also, OpenVPN is an open-source VPN solution which is useful for site-to-site VPN creation without having to spend a lot of money on a Cisco or Juniper solution.

Included in encryption would be TrueCrypt for file, folder and disk encryption solutions. It's open source, very flexible and provides extremely robust encryption options for a merchant.

Among other useful tools that a merchant's network security team should use to test the strength of their network is Zenmap for port and host scanning, and Firewalk for checking ACL configurations. Password crackers are useful for the security team to verify that passwords are configured properly. Some useful password tools are Aircrack (for wireless scanning), John the Ripper, and Cain and Abel. A favorite network service password tester of mine is Brutus which tests services such as FTP, Telnet, IMAP, POP3 and others that are sometimes available on a network.

It's important to keep in mind if a merchant chooses to stick to an open-source approach to assist with PCI compliance, the majority of the open-source security tools available only run in a Linux and/or UNIX environment. Therefore, network security staff or consultants need to have familiarity with this kind of environment.

Lastly, all of these tools and many others are discussed conveniently in one place: http://sectools.org/.

December 24, 2008

Deming Points Applied to Security

The following is a guest post by Phil Fuhrer. Phil has many years of experience in the assessment and management of IT systems quality. In addition to his current work at VeriSign his interests include requirements, systems architecture and security technology.

Edward Deming is considered the father of statistical quality control .The "Deming Cycle" and his fourteen points for managing quality improvement are the most widely known parts of Deming's work.

The "Deming Cycle" is much like the Systems Development Life cycle and other methods that ratchet change allowing continuous improvement. Less well known is Deming's insistence that effective quality improvement can not be done without statistically stable quality measurements (Bell Laboratories Deming Quality class about 1996). As a statistician he recognized that attempting to improve an unstable or poorly understood system is non-scientific tampering.

The fourteen points are rooted in the idea that management must advocate quality in non-production line systems where success and failure cannot be counted or otherwise easily measured.

Security is a type of quality and cannot be measured by counting successes and failures. Restating Deming's fourteen points as security directives is a useful way to direct security management.

Deming's 14 points for management paraphrased and their security implications are:

1."Create constancy of purpose towards improvement". Replace short-term reaction with long-term planning. - Assessment, testing and compliance evaluation are tools to identify defects. Further analysis should be done to identify the root cause of defects and to systematically improve the processes that determine security level.

2."Adopt the new philosophy". The implication is that management should actually adopt his philosophy, rather than merely expect the workforce to do so. Often security as other quality dimensions only receive upper management attention when there is an abject failure causing resulting high cost or low profit. Management should adopt a security policy.

3."Cease dependence on inspection". If variation is reduced, there is no need to inspect manufactured items for defects, because there won't be any. - In security inspection should be built into production processes and not considered separate or add on.

4."Move towards a single supplier for any one item." Multiple suppliers mean variation between feed-stocks. - In security variation can be caused by overly complex interfaces between software suppliers and by incorrect or malicious user input.

5."Improve constantly and forever". Constantly strive to reduce variation. - As with other quality dimensions there is no such thing as perfect security.

6."Institute training on the job". If people are inadequately trained, they will not all work the same way, and this will introduce variation. This applies to both production and development staff. Security (as other quality) training is inadequate when it creates machine-like rote behaviors that reduce attention to variation (unusual security risks).

7."Institute leadership". Deming makes a distinction between leadership and mere supervision. The latter is quota and target-based. This fits for security.

8."Drive out fear". Deming sees management by fear as counter- productive in the long term, because it prevents workers from acting in the organization's best interests. This fits for security.

9."Break down barriers between departments". Another idea central to TQM is the concept of the 'internal customer', that each department serves not the management, but the other departments that use its outputs. In security while some barriers between production and development are needed, finger-pointing and miscommunication must be addressed.

10."Eliminate slogans". Another central TQM idea is that it's not people who make most mistakes - it's the process they are working within. Harassing the workforce without improving the processes they use is counter-productive. Security management by slogan is not effective.

11."Eliminate management by objectives". Deming saw production targets as encouraging the delivery of poor-quality goods. Real productivity is not measured by volume alone. Security and other difficult to measure quality dimensions should not be short changed.

12."Remove barriers to pride of workmanship". Many of the other problems outlined reduce worker satisfaction. This fits for security. Workers should take pride in Identifying potential security holes.

13."Institute education and self-improvement". This fits for security.

14."The transformation is everyone's job". This fits for security.

December 22, 2008

What the new Service Provider levels mean to you!

The following is a guest post by Rob Harvey. Rob is a Consulting Manager inside the PCI practice at VeriSign.

'Tis the season!

Everyone is in the giving mode this time of the year and VISA is no different. VISA announced in the last month a change in the service provider validation levels and reporting. It is also the season for reflecting on the past year and one of the biggest questions we get from our clients is, "Am I a service provider and if so what level do I need to validate against?"

Beginning February 2009, VISA will use a modified two level approach for service providers which I hope will add clarity to the question. See the information on VISA's website.
(http://usa.visa.com/merchants/risk_management/cisp_service_providers.html)

"Am I a service provider?" By definition from VISA, service providers are organizations that process, store, or transmit Visa cardholder data on behalf of Visa clients, merchants, or other service providers. Some examples of service providers are transaction processors, payment gateways, Independent Sales Organizations (ISO) or External Sales Agents (ESA), credit reporting services, customer service functions, plastic card embossing, remittance processing, managed security service providers, and hosting providers.

This past week proved my point that organizations may not realize they are acting as a service provider in addition to their merchant obligations. Management for a L3 merchant (~750,000 annual ecommerce transactions) knew they needed to comply with the PCI DSS but only to submit a questionnaire and quarterly scanning to their acquirer for validation. After further review, they offer payment gateway services to their direct sales consultants (read: independent contractors / merchants).

So, I am a service provider, "What level am I?" VISA offers the following guidance:

  • Level 1 - VisaNet processors or any service provider that stores, processes and/or transmits over 300,000 transactions per year
  • Level 2 - Any service provider that stores, processes and/or transmits less than 300,000 transactions per year

VISA combined levels 1 and 2 in addition to lowering the amount transactions from million per year to 300,000. This change means that many service providers that could self assess are now elevated to Level 1 status, requiring a full on-site assessment.

If this is a revelation that you were not ready for, drop us a line! We can help!

December 19, 2008

Happy Holidays to you and yours!

2008 is almost done and the next two weeks hold some of my favorite times of the year. This is my last post for 2008, but don't stray too far! I have lined up some excellent guest posts for you over the next two weeks.

Before I let you go, I wanted to list for you the top X favorite posts from this year. These are posts that I enjoyed writing and in many cases caused some of you to reach out and chat with me! If you are a new reader to this blog, take a tour down memory lane with me! In no particular order, they are:

I hope you enjoyed this blog this year, and I hope you can take the time to introduce yourself at the next conference we are at, or at a minimum, drop me a line!

See you in 2009!

December 18, 2008

ACK! No browser is safe!!

What a confusing time it is for me those of us who just like sitting around all day and poking at the interweb through a browser. We have a rather nasty 0-Day exploit for Internet Explorer roaming around, and Mozilla Firefox makes Bit9's list as one of the most vulnerable applications in 2008 (surprisingly, IE is not on there).

The Internet Explorer 0-Day is so bad that some experts are urging users to switch to another browser. Naturally, the first choice for a number of users would be Firefox. But now Bit9 has released this telling report saying that it was one of the most vulnerable apps in 2008.

So where do you turn? Well, the list is not the prettiest. You could go with Chrome, but then you read the EULA. You could try Opera or Safari, but both have also seen major security vulnerabilities this year.

Maybe it's just time to punch out for 2008?

December 16, 2008

Something is afoot with Cloud Computing

Something is going on. I don't know exactly what it is, but all the sudden I'm hearing more of this buzzword. "Cloud Computing" may be the buzzword for 2008. There are even blogs that dedicate content to it.

It sure seems to be thrown around a lot... especially in the economic hiccup we are experiencing right now.

Should we blame Gartner for its use? Only for using cloud computing and $3.4 trillion in the same article. I bet that's the root of the problem.

So what is cloud computing? Well, according to IEEE, "Cloud Computing is a paradigm in which information is permanently stored in servers on the Internet and cached temporarily on clients that include desktops, entertainment centers, tablet computers, notebooks, wall computers, handhelds, sensors, monitors, etc." Essentially, a mashup of Software as a Service (SaaS), virtualization, and potentially even Service Oriented Architecture (SOA). I suggest that it is destined to become a generalization that has no real meaning on the surface, but requires detailed questions and answers before its true meaning is known.

That's where security comes in. When looking at doing anything with cloud computing, security professionals must understand exactly what is going on. The leveraged resources used to allow for cloud computing to work means that you have a lot of co-mingling of things. Data and systems that need to be kept secure will mingle with data and systems that don't. The whole strategy of using segmentation as a scope reduction technique (or just good practice) goes out the window with this type of infrastructure. Unless, of course, you create multiple clouds, but then that kind of ruins the whole paradigm, doesn't it?

As with most technology, there is a place for cloud computing in our infrastructure. It should neither be immediately shunned or lauded. Instead, do the due diligence required to get a clear picture of how it may impact your enterprise.

December 15, 2008

Past Issues of Herding Cats now ONLINE!

Herding Cats is the monthly column that I write for the ISSA Journal. If you have read my previous posts on Herding Cats, you probably noticed that the links require membership in the ISSA. If you are a reader of this blog and NOT a member of the ISSA, you should join today.

Society membership rant aside, I now have a small page that has all of my past columns and publications for the Journal. Please navigate over to http://www.brandenwilliams.com/brwpubs/ to download those versions! These will be posted one month behind the printed version.

Navigate over and enjoy!

December 11, 2008

PCI 1.2 is translated!

The PCI Security Standards Council recently published translated versions of PCI version 1.2! The Standard is now available in Chinese (Simplified and Traditional), German, French, Italian, Japanese, Portuguese, and Spanish.

December 10, 2008

PCI 1.2 is taking off!

Less than two months after its release, we've seen our first announcement from a company that has become compliant!

I think that companies will find 1.2 easier to comply with when they examine it in detail. Have you performed a gap analysis yet? If not, maybe the downtime around the holidays (as long as it does not impact holiday lockdown!) would be good to review your last ROC and see what changes you may need to make!

December 9, 2008

BUSTED! Why passing the blame for a PCI Breach will fail.

After the year we had in 2007 with PCI related breaches, who would have thought that 2008 would give us more? I mean, after last year, who would have thought that we would see another major breach given the "lessons" we learned?

Um, I did. Fo-sho.

Why? Because early in my career I learned that most executives don't care about problems until they hit close to home. Like right under their nose.

We've seen two instances this year of companies that had validated compliance with a QSA, but were subsequently breached. Without specifically commenting on either of these cases, we have never conducted an investigation of a compromised entity and learned that they were compliant at the time of the breach. I've written about the quality of QSAs and the corporate responsibility, but as Will Smith so eloquently explained, parents just don't understand.

Many retailers are struggling right now. Guess what one of the first programs to get cut will be? YEP! The one that will prevent that breach from actually occuring.

One common theme I am seeing in many of my large retail customers is they seem to think that they will be able to transfer the liability of a breach to their QSA. I worry when I am sitting with a manager of the PCI program and he or she asks what is "passable" or something we can "cobble together for the QSA" knowing that it won't last past the QSA's flight out.

Don't laugh, this has happened multiple times this year. Or if you want to laugh, just giggle silently to yourself while making sure this won't happen to you.

If you are wondering what kind of liability a QSA carries, you can read the publicly available Validation Requirements for Qualified Security Assessors (QSA) v. 1.1. If you are at work and don't want to slip into a post-lunch coma by wading through this, here's the gist of it.

QSAs are liable for improperly performing the assessment, and willfully passing someone that should not be passed. We have to assemble a considerable amount of documentation when doing these assessments to justify our position. If there is ever a review, we have to show how we arrived at our conclusion. If we are unable to, there is where the liability can come into play.

If a merchant hides things and get's lucky because sampling did not find issues known by the merchant, the QSA may or may not have liability here. It depends on the circumstances, and more importantly, the lawyers. None of these clauses have been tested yet (to my knowledge) in a court, but that will change based on the events of 2008.

Regardless, as a merchant, you should not want to ever GET there. Brand damage aside (which I will argue may not be relevant in many cases), the fines that must be paid pale in comparison to the fees you will pay to lawyers and vendors to hastily assemble a compliant and secure solution.

Merchants must own and be responsible for compliance every day of the year. This means actually being compliant, expanding on compliance to become secure, and finally having a program in place to monitor and maintain that compliance 24x7.

December 4, 2008

Security Bloggers Network has a new home!

With Feedburner finalizing its integration with Google, some of the features that we are used to are going away. One of those is the ability to quickly aggregate feeds.

If you are interested in TONS of content on Security, you should add the Security Bloggers Network to your RSS feed Aggregator. You will see this blog included with many other prominent security blogs in one convenient feed. Go check it out!

December 3, 2008

Your Doctor does not take Security Seriously

Probably.

Well, at least one of mine doesn't. Let me take you through the scene I lived as I completed a routine checkup at my doctor's office last week.

After arriving and being called back, they did the standard how tall are you (thankfully, I have not shrunk), how much do you weigh (PRE-thanksgiving, thanks!), do you have a pulse, and is your blood pressure somewhere in between dead and explodingly high.

Yep, I said it. Explodingly. It's a smashup between a gerund and an adverb. An "adverunderb."

So after all the basic stuff, we sit down and review my medical history as they have it, including any surgeries or medications I have been on prior to my visit. As we're going through this, I noticed that they listed a medication that I have never been on. After watching the nurse edit my data in the practice's medical software, I wonder what it would be like if a doctor's office had a compromise. It's not too far fetched. Most store patient records electronically now, and many allow internet access right there from their PCs so that the receptionist can update her Facebook between opening and shutting the big sliding glass window.

Electronic medical records can be a good thing. Ask any of the MBAs that made a ton of cash selling computer illiterate MDs on how they can save time and money by investing in this wacky computer fad. But the risks associated with keeping this data electronically are significant.

Now here's where things get interesting.

So the doctor walks in, and what do you know, she types her FOUR DIGIT NUMERIC PASSWORD to log in. And it was not like she was using the numbers above the QWERTY part of the keyboard, she was using the 10-key numeric pad. Right next to me. Easiest password I ever shoulder surfed.

EVER.

Of course her little numeric password then gave her access to my entire medical history, including things like a copy of my drivers license, social security number, and medical insurance information and card. Think of the identity theft fun you could have with that!

So what are we to do? I will put this in the bucket of corporate responsibility. If your corporation is going to put technology in the hands of your employees, you are responsible for making sure they know how to use it securely and appropriately. Regardless of your company's size, or the type of technology being deployed.

And if I were a bad guy, this is the type of gold mines I would be going after.

PA-DSS Validated Applications Published

The transition of PABP to PA-DSS looks more complete every day. In the last 24 hours, the PCI Council has posted their validated application list. Many of these applications were grandfathered under various versions of PABP and will have to be reviewed under PA-DSS in the next one to two years.

As of today, 85 payment applications are listed from 55 vendors.