Five Characteristics of Secure Online Services

* Manage the actual secure service on infrastructure that is distinct and separate from other business infrastructure (e.g., the public-facing Web site). This ensures that security breaches affecting the company’s IT infrastructure in other areas will not provide easy access to customer data.

* Offer a means of interacting with the service where data encryption happens on the client-side, before any data gets sent to the service, if at all possible. This would mean that customers can be sure you, any shady or disgruntled employees (or ex-employees), and anyone compromising your service’s IT infrastructure in any way will not have access to unencrypted customer data or decryption keys for that data. Never forget that privacy is security.

* Provide client software not only as binary executables but also as source code that can actually be compiled (or interpreted) and used by the customer, lacking nothing. This means no omitted DRM source or elided trade secrets. The only way a customer can be absolutely certain that there is nothing shady going on in your source code is via technically proficient people who can examine the source on the customer’s behalf, following which the exact source that was examined is the code that the customer uses, ensuring that a bait-and-switch was not used to lull the customer into a false sense of security. While such source code could be offered under a nondisclosure license or agreement, there are security benefits for a well-managed open source project — such as security through visibility.

* Create and manage a mechanism for transparent two-way communication with customers regarding security matters. This can take the form of a public bug tracking system, for instance, so that people have an easy way to inform you of technical issues, to see what issues might currently affect them as customers, and to follow your progress in addressing these issues. To the extent you actually care about customers’ security needs, security notifications should be handled transparently.

* Pay particular attention to making sure customers know how to interact securely with the service, and to providing a secure procedure for interacting with the service that makes it easier for the customer to do the right thing than to do the wrong thing. Interface design is security design, after all.

These are the sorts of security policy points you should employ when designing an online service for customers, if that service handles any sensitive data. Keep them in mind if you are a service provider reading this article. When you’ve put together what you are sure is a sound plan for offering a service whose security can be verified by the customer, make sure you do not forget to let the customers know how they can verify that security.

You should also keep in mind that some of your would-be customers may be reading this article as well — and if you do not address these security policy points, you may lose those potential customers.

Google is Obsessed with Phishing

People associate phishing with identity theft. That’s bad enough, but there is something else to consider. If phishing continues to be successful, people will be afraid to do anything online, especially when it requires disclosing personal information.

Businesses, financial establishments, and companies who exist because of the Internet are keenly aware of this. It seems that Google, one such company, has decided to bring their vast arsenal of technology to bear on the problem of phishing.

There are two reasons why I am interested in Google’s approach to anti-phishing. First, their Anti-Phishing Team has been able to automate the black-listing process, no small feat. Second, they are finally talking about how they do it. Their method involves two parts, a client-server interface and the backend data base. Let’s look at the client-side service first.

Client side

The client interface is Google’s Safe Browsing API. It has been working quietly in the background for several years. A fact many do not realize. Three of the four (edited to reflect Internet Explorer’s ranking) big-name Web browsers Firefox, Safari, and Chrome use it. Google defines the Safe Browsing service as:

“At a high level, the service works by checking each URL the client loads against a list of known phishing and malware sites. The list of known sites is represented as host-suffix / path-prefix expressions.

As the name suggests, these expressions can match arbitrary URLs as long as they have the required host suffix and path prefix. This approach helps protect against sites where the attacker uses many different URLs in order to try to evade blacklists.”

The following diagram (courtesy of Google) is a visual description of the look-up process:

The client-server handshake is the easy part. Trying to keep the black list current, have minimal mistakes, and even fewer false positives is where it gets tricky.

Back end

Until recently, Google has kept mum about how their black list is populated. I first learned about it through a Google blog post. It pointed me to the paper Large-Scale Automatic Classification of Phishing Pages (pdf). Now public, after being presented by Colin Whittaker, Brian Ryner, and Marria Nazif (all members of Google’s Anti-Phishing Team) at the 17th Annual Network and Distributed System Security Symposium.

Right away in the report, the team discusses what is needed for the black list to be effective:

* Comprehensive: A blacklist that is not comprehensive fails to protect a portion of its users.
* Error free: False positives subject users to unnecessary warnings. Eventually, the users will ignore the warnings.
* Timely: The black list must update in real-time. As most phishing sites are up for less than a day.

The report goes on to explain that the automatic classifier (back-end algorithmic process) uses the following Web-page elements in the decision-making process:

* Page URL: Look for anything odd about the hostname. Is it unusually long or possibly contain an IP address.
* Page content: The page is checked to see if it has a password and or PIN field. Additionally, the page is checked for links that may be pointing at a known phishing domain.
* TF-IDF score: TF-IDF is a ranking method used when automatically scanning for phishing sites. Through the magic of mathematics, important terms like “password” or “PIN” are given more weight.
* Hosting information: What network hosts the Web site and where the Web servers are located geographically can be telling. For example, I’d be concerned if the Web server for an American bank is in a different country.
* PageRank: PageRank is used to determine the spam reputation of the page’s domain. Apparently, the Anti-Phishing Team has discovered a relationship between phishing pages and domains that send spam.

That’s quite a list of things to check. More than I would care to check each time I go to a new Web site.

Automated

Automating the search for the above elements is the first step the Anti-Phishing Team did and probably the simplest. The classifier then takes the information and ranks the URL, from 0.0 not at all phishing to 1.0 definitely phishing. Finally, software called the Blacklist Aggregator prepares the list to be served to the clients.

What really makes this system effective is how the classifier is retrained every day to pick up new phishing trends. Google explains:

“As a training data set, we use a sample of roughly ten million URLs analyzed by the classification workflow over the past three months along with the features obtained at the time.”

The report goes on to explain how the training data set is manipulated to test the classifier and make sure it is providing the most accurate results possible. From what I understand, the training process is the heart of the classifier and what separates Google’s approach from others.

A different take

Another Google blog post I came across looks at phishing differently.

The post explains how Web-site designers can minimize the chance of having their work trigger anti-phishing scanners. After reading the post, I realized these points are something we should keep in mind as well:

* Beware of username and password requests that are not specifically for that Web site.
* Be leery of logos near login fields that are not related to the Web site.
* Links to other Web pages should be readily viewable and related to the site’s domain page.

The above bullet points are important, but easily missed. I was almost tricked by a password request that had nothing to do with the Web site I was viewing.

Report’s conclusions

A short while ago, I wrote a piece about users and rejecting security advice. One of the premises I wrote about is how difficult it is to keep track of all the anti-phishing rules, so we don’t. I am heartened by reports like this one from the Anti-Phishing Team. Their conclusions offer the following encouragement:

“In this paper, we describe our large-scale system for automatically classifying phishing pages which maintains a false positive rate below 0.1%. Our classification system examines millions of potential phishing pages daily in a fraction of the time of a manual review process. By automatically updating our blacklist with our classifier, we minimize the amount of time that phishing pages can remain active before we protect our users from them.

Even with a perfect classifier and a robust system, we recognize that our blacklist approach keeps us perpetually a step behind the phishers. We can only identify a phishing page after it has been published and visible to Internet users for some time. However, we believe that if we can provide a blacklist complete enough and quickly enough, we can force phishers to operate at a loss and abandon this type of Internet crime.”

Final thoughts

Automated filters aimed at reducing phishing attacks are vital to the existence of the Internet as we know it. There may be other answers, but until they are turned into working systems, this seems like our best bet.

I also feel the more informed we are about phishing, the safer we will be. Call it the belt and suspenders approach.

Cyclic Redundancy and Parity Checks

Cyclic Redundancy

A cyclic redundancy check (CRC) can check for a block of transmitted data. A workstation can generate a CRC and transmit it with data. The receiving workstation computes a CRC and compares it to the transmitted CRC. If both of them are equal, then the block is assumed error free. In this case  multiple errors can be detected. In general, CRC can detect all single-bit and bubble-bit errors.

Parity Checks

This check is known as the “vertical redundancy check” and involves adding a bit (known as a parity bit) to each character during transmission.

What is a Protocol Analyzer?

Protocol Analyzers are network diagnostic tools that monitor and record network information from packets traveling in the link to which the analyzer is attached.

An example of a protocol analyzer is Wire Shark.  Wireshark is the world’s foremost network protocol analyzer, and is the de facto (and often de jure) standard across many industries and educational institutions.

On wired broadcast LANs, depending on the network structure (hub or switch), one can capture traffic on all or just parts of the network from a single machine within the network; however, there are some methods to avoid traffic narrowing by switches to gain access to traffic from other systems on the network (e.g. ARP spoofing). For network monitoring purposes it may also be desirable to monitor all data packets in a LAN by using a network switch with a so-called monitoring port, whose purpose is to mirror all packets passing through all ports of the switch when systems (computers) are connected to a switch port.

The versatility of packet analyzers means they can be used to:

• Analyze network problems
• Detect network intrusion attempts
• Gain information for effecting a network intrusion
• Monitor network usage
• Gather and report network statistics
• Filter suspect content from network traffic
• Spy on other network users and collect sensitive information such as passwords (depending on any content encryption methods which may be in use)
• Reverse engineer proprietary protocols used over the network
• Debug client/server communications
• Debug network protocol implementation

How to Design SSL VPN Solution

There are 5 major components to design an SSL VPN Solution

1) Access Control – Design an access control policy. SSL VPN users may gain access to particular resources based on characteristics such as user identification, computer type and location, and the method of authentication.

1) List the resources that will be accessed through the SSL VPN

2) List the groups and users

3) List the conditions under which the resources should be accessible by the groups

4) List how the VPN should be used to access the resources

2) Endpoint Security – Design the endpoint security controls. SSL VPNs provide endpoint security controls that include host integrity checking and security protection mechanisms. Host integrity checks ensure that the client system is in compliance with an organization’s minimum security policy. Typical host integrity checks may look for operating system type and version, antivirus and personal firewall status and configurations, or a specific file, registry key, or process that is running.

If an organization has an endpoint security policy, it should deploy SSL VPN devices that can support those policies. This is especially important because endpoint security controls vary widely by device and vendor. As with authentication, each organization should conduct testing during its evaluation process to determine the endpoint security capabilities of each device being considered.

3) Authentication - Select the authentication methods. There are many ways to authenticate SSL VPN users, including LDAP, RADIUS, Active Directory, and digital certificates.

SSL VPN authentication methods may be applied on an individual or group basis. An organization can select one form of authentication for one group, and another form of authentication for a different group.

Because integration with authentication servers is an area where SSL VPN products vary greatly, an organization should ensure that whatever product it chooses is able to support its authentication requirements. Any potential products should also be tested with the existing authentication servers to verify interoperability.

4) Architecture – Designing the architecture of the SSL VPN implementation includes hardware selection, device placement, firewall and routing considerations, client software selection, high availability configuration, and portal design.

There are 3 main types of hardware configuration: a hareware appliance, an upgrade to an existing security product, and a software solution.

A hardware appliance is a device running the SSL VPN software that has been hardened by the SSL VPN device vendor to make it more secure.

Some existing security products such as firewalls or IPsec VPN gateways can be upgraded to support SSL VPNs. This option is made available by the vendor as either a software upgrade or a hardware module that is installed into the existing security device.

A software solution that is installed on standard hardware, such as a server built by the organization. The hardware can either be used to support a dedicated SSL VPN service or to support other services such as a firewall or IPsec VPN.

Device placement of the SSL VPN hardware is often a challenging task because the placement has security, functionality, and performance implications. It may also have an effect on other network devices such as firewalls, routers, and switches. Incorporating SSL VPN devices into a network architecture requires strong overall knowledge of network and security policy.

There are three main options for SSL VPN placement: as part of the organization’s firewall, within the internal network, or within a demilitarized zone (DMZ). Placing the SSL VPN device outside the organization’s firewalls is not recommended because the device itself receives no protection from the firewall.

5) Cryptography Policy and FIPS Compliance – The organization must choose a cryptography policy that fits its needs and is compliant with its requirements. In addition, Federal agencies must use only cryptographic modules that have algorithms and methods that are compliant with the FIPS 140-2 specification.