October 2008

You are currently browsing the monthly archive for October 2008.

Managed Security Services Moving into the Cloud

There is a sea change underway in the managed security services marketplace.  This change is from a premises-based model to a cloud-based one.  The traditional managed security services model works like this.  An organization that does not have the resources or desire to manage its own security devices will contract with a managed security services provider (MSSP) to do it for them.  Taking the firewall as an example, the MSSP places a firewall at the customer premises, configures and manages it remotely for the customer in exhange for a monthly fee.  The customer does not have to purchase any hardware or software, perform any maintenance, or manage it in any way.  They may receive periodic reports or may be contacted in the event of a fault, but for the most part they are happy knowing this part of their network security is being managed for them.

There are several problems with this type of premises-based service:

  • First, it is not very efficient.  It often requires feet on the street to resolve hardware problems which can eat into profits.  And premises-based devices can be difficult to manage remotely.  Also, it doesn’t make sense to setup a firewall at the customer site to block traffic that could just as easily be blocked at the other end of the circuit before it even reaches the customer’s network.
  • Second, it does not address an increasingly mobile workforce.  This is particularly true for services geared toward endpoint security.  What good does it do to have a proxy or secure web gateway at headquarters if remote staff access the Internet directly?  Sure, you can back haul traffic via a VPN, but this can cause performance issues.
  • Third, premises-based solutions do not scale well.  It becomes increasingly difficult to effectively manage hundreds or even thousands of premises-based devices.

To address these issues, MSSPs have begun moving their security services into the cloud.  This means that there is no need to place any hardware at the customer site.  Turn-up is usually quick and painless which is a positive for the customer as well.  An early example of a cloud-based security service is email anti-virus and anti-spam.  Several vendors, such as Postini, route customer email through their network where it is scanned and cleaned before being routed to the customer.  This same model is being used by companies such as ScanSafe who proxy their customers’ web traffic through their networks and perform AV scanning, URL filtering, anti-phishing and other security services on behalf of their customers.

But most of these companies have been focused on a single service such as anti-spam or anti-virus.  And now ISPs have begun to realize that they can provide these services as well.  In fact, many of the largest ISPs on the planet also provide premises-based security services and they see a huge market for cloud-based services.  If they are already providing Internet services to a customer, why not also protect their traffic?  Need a firewall, we can do that.  Need IDS, we got that.  URL filtering?  No problem.  For the customer it is seemless.  And for the ISP it is additional revenue with little additional cost.  This transition is already underway.  Expect to see more and more cloud-based security services being offered from ISPs in the very near future.

Hiding in Pictures

Take a look at the two images below. Can you tell which one has a message hidden within it?

Even though it is impossible to notice, the image on the left has a hidden text file in it. The hidden message says:

“This is a test file used in my steganographic encryption fun.

https://infosecstuff.com”

I created the text file using Notepad, and then used a tool called to embed the text file within the image. This is an example of steganography, one of the most fascinating fields of cryptography.

Steganography is not anything new. In fact, it dates back thousands of years. The ancient Greeks and Romans would often hide messages that they did not want to be intercepted using various means. In more recent times, steganographic techniques were used during World War II. And it is believed that terrorists use this method today to communicate messages securely. Basically, steganography is the hiding of messages such that the presence and contents of the message cannot be detected or revealed. In the digital age, it has come to mean the hiding of messages usually within image, sound or video files.

So how does this work? Steganographic tools take advantage of the fact that the least significant bit (LSB) of a binary file can be changed without altering or destroying the file significantly. In fact, many other security techniques such as hash functions and checksums also manipulate the LSB for their purposes. The file you are hiding must be smaller than the one you are using to hide the message and it works best for small messages. Larger hidden messages can result in the distortion of the original file which will make it easier for others to detect the hidden message.

Steganography has many applications including digital watermarks and the protection of private information.  But it can also be used for fun and cool home projects.  is a clever example of using steganography as a party sign or even a home decoration by my colleague Bob.  How cool is that!

PCI DSS 1.2

Last week the Payment Card Industry Security Standards Council (PCI SSC) released the first update to the Data Security Standard (DSS) in more than two years. Version 1.2 of the DSS provides some much needed updates and clarifications to the 1.1 version of the document and is the official document as of October 1, 2008. While the standards council claims not to have introduced any new requirements in this version of the document, some of the changes are significant and represent more than just clarification. During a recent PCI DSS security assessment, I found the following changes to be most noteworthy:

  • Compensating Controls

The PCI DSS version 1.2 has much stricter language with regards to compensating controls. Every compensating control must be reviewed, documented and validated by an assessor annually. Furthermore, for each compensating control the Compensating Control Worksheet must be completed. These changes clearly signal the security council’s intent to make it more difficult for merchants to use compensating controls rather than meeting the requirements of the DSS.

  • WEP Encryption

WEP encryption for wireless networks may no longer be implemented for new networks after March 31, 2009. And wireless networks currently using WEP encryption must migrate to industry best practices (e.g. 802.1x) by June 2010. While these requirements are not terribly difficult to meet, merchants need to be aware of this as they roll out new wireless networks or plan to upgrade current WEP enabled WiFi networks.

  • Anti-Virus Software

Both versions 1.1 and 1.2 of the PCI DSS state that anti-virus software must be deployed on “all
systems commonly affected by malicious software (particularly personal computers and servers).” However, in version 1.2 the security council removed a note stating that viruses typically do not affect Unix-based systems and mainframes. This has led some to interpret the requirement to mean that ALL systems must run anti-virus software. However, I would argue this is not the case. The requirement does state “systems commonly affected my malicious software.” To me this would not include mainframes or i-series systems from IBM for example. One could even argue that Solaris, Apple, and Linux systems are not commonly affected by malicious software. My advice would be to run it wherever possible and practical.

  • Patch Installation

The new version of the standard provides more leeway in the patch installation process. Version 1.1 specifically required that security patches be applied within 1 month of release. The new version allows companies to apply a risk based approach which fits better into most enterprises’ vulnerability management programs and will ultimately lead better overall security. Patches can be applied to more critical systems first and less critical ones can be updated later.

  • Video Cameras

Version 1.1 of the DSS required the use of video cameras to monitor sensitive areas. The new version provides the possibility of using other access control mechanisms to monitor access to sensitive areas. Potentially this could include card keys that would provide a date and time stamp each time someone entered a data center for example. Biometric access control mechanisms could also be employed. Standard keys and keypads would NOT meet this requirement as they do not provide the ability to monitor access to sensitive areas.

  • Service Providers

Version 1.2 of the DSS provides more detailed requirements when dealing with service providers that have access to cardholder data. The merchant must maintain a list of all such service providers, ensure that the service providers are PCI DSS compliant and monitor their compliance, maintain a written contract with the service provider stating that they are responsible for the cardholder data, and establish a process when selecting service providers to perform due diligence. These requirements force merchants to work much more closely with their service providers and be aware of their service providers’ PCI DSS compliance status.

To view the new version of the PCI DSS as well as other related documents, go the official PCI SSC web site at .

Copyright © 2011 InfoSecStuff.com — All Rights Reserved