The Predictability of URL Filtering

While changes (fine-tuning) to a heuristic system often have unpredictable consequences, additions to URL filtering are absolutely predictable – it will block one spam campaign and nothing else. For example, consider a legitimate newsletter from drugstore.com (a legitimate retailer) that advertises various health products and perhaps has “free” offers. Many heuristic systems will have trouble accepting this as a legitimate email due to “spam-like” content. Because SpamStopsHere almost completely ignores normal content, this email would not be blocked.

Now consider a spammer that takes the drugstore.com newsletter and changes all URL links from drugstore.com to drugstorerx.com (assuming this is the spammer’s domain and website), and then sends this to a huge email list. This would be a heuristic system’s nightmare. First the spammer’s newsletter would likely not be blocked; then after many user reported the spam, the legitimate newsletter would also be blocked in the future.

With URL filtering, only the drugstorerx.com domain needs to be added to the blocking database. If not already in the blocking database, the SpamStopsHere technology would likely add it automatically and then have its 24/7 staff confirm it.

With URL filtering, the legitimate drugstore.com newsletter will never be blocked while the spammer’s newsletter (with nearly identical content) will be blocked 100%. Also, with URL filtering, the anti-spam vendor can determine precisely what will be blocked by policy. For example, the vendor can decide to block all emails that link to pornographic, casino and betting sites. Without blocking even vulgar personal emails, or discussions about casinos.

Built-in Compliance Capabilities

Advanced, built-in security protection and remote auditing help your organization comply with industry security standards, including Payment Card Industry Data Security Standard (PCI DSS), HIPAA, Basel II, and SOX, in a cost-effective way—without requiring multiple appliances, application changes, or rewrites. BIG-IP ASM reports previously unknown threats, such as layer 7 denial-of-service (DoS) and SQL injection attacks, and it mitigates web application threats to shield the organization from data breaches. All reports are GUI-driven and provide drill-down options with a click.

PCI reporting

With PCI reporting, BIG-IP ASM lists security measures required by PCI DSS 1.2, determines if compliance is being met, and details steps required to become compliant if not.

Geolocation reporting

Geolocation reporting informs you of the country where threats originate in addition to attack type, violation, URL, IP address, severity, and more. You can also schedule reports to be sent to a designated email address automatically for up-to-date reporting.

Easy-to-read format for remote auditing

BIG-IP ASM makes security compliance easier and saves valuable IT time by exporting policies in human readable format. The flat, readable XML file format enables auditors to view the policies off site. Auditors working remotely can view, select, review, and test policies without requiring time and support from the web application security administrator.

What is Extreme Programming?

Kent Beck, author of Extreme Programming Explained says, “XP is a light-weight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.” Simply stated, XP is a set of values, rights and best practices that support each other in incrementally developing software. XP values Communication, Simplicity, Feedback and Courage. Programmers and Customers have the right to do a quality job all the time and to have a real life outside of work.

XP is a collection of best practices. Some may sound familiar. Some may sound foreign.

Customer Team Member – Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product.

Planning Game – XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimating the feature costs. Customers select features and package the development of those features into small iterations (typically 2 weeks). Iterations are combined into meaningful end user releases.

User Story – A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration.

Small Releases – Programmers build the system in small releases defined. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.

Acceptance Testing – The customer writes acceptance tests. The tests demonstrate that the story is complete. The programmers and the customer automate acceptance tests. Programmers run the tests multiple times per day.

Open Workspace – To facilitate communications the team works in an open workspace with all the people and equipment easily accessible.

Test Driven Design – Programmers write software in very small verifiable steps. First, we write a small test. Then we write enough code to satisfy the test. Then another test is written, and so on.

Metaphor – The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, making the software communicate to the programmers.

Simple Design – The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don’t build frameworks and infrastructure for the features that might be coming.

Refactoring – As programmers add new features to the project, the design may start to get messy. If this continues, the design will deteriorate. Refactoring is the process of keeping the design clean incrementally.

Continuous Integration – Programmers integrate and test the software many times a day. Big code branches and merges are avoided.

Collective Ownership – The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes.

Coding Standards – The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style.

Pair Programming – Two programmers collaborate to solve one problem. Programming is not a spectator sport.

Sustainable Pace –The team needs to stay fresh to effectively produce software. One way to make sure the team makes many mistakes is to have them work a lot of overtime.

smartX model for smart card application deployment

In this model, we assume OCF (OpenCard Framework) and the smartX engine are initially installed and configured on the target terminal. As explained in the previous section, the terminal application consists in two blocks: the application process and the application protocol. The application process that encapsulates the logic of the application is compiled into a Java applet signed by a trusted entity. The application protocol is described inside an SML dictionary and is card-specific. Once the Java applet is downloaded, the smartX engine identifies the smart card inserted in the terminal. A simple identification consists in verifying the historical bytes of the card ATR (Answer To Reset). After correct identification, the smartX engine dynamically downloads the SML dictionary that contains the application protocol for the card inserted inside the terminal. With this dynamic mechanism, you minimize the loading time since you only download the dictionary relevant to the card inside the terminal.

In the OCF model, you had to download with the applet all the CardService implementations. With smartX, a terminal is also not limited to a predefined set of smart cards. As long as you provide the correct SML dictionary, a terminal can dynamically accept a new smart card that was not originally supported by the application. All these advantages make smartX a platform of choice for developing and deploying smart card applications on the Internet.

The Priority Ceiling Protocol

Each shared resource has a priority ceiling that is defined as the priority of the highest-priority task that can ever access that shared resource. The protocol is defined as follows,

• A task runs at its original (sometimes called its base) priority when it is outside a critical section.
• A task can lock a shared resource only if its priority is strictly higher than the priority ceilings of all shared resources currently
  locked by other tasks. Otherwise, the task must block, and the task which has locked the shared resource with the highest priority ceiling inherits the priority of task.

An interesting consequence of the above protocol is that a task may block trying to lock a shared resource, even though the resource is not locked.  The priority ceiling protocol has the interesting and very useful property that no task can be blocked for longer than the duration of the longest critical section of any lower-priority task.

Priority Ceiling Protocol Emulation

The priority ceiling of a shared resource is defined, as before, to be the priority of the highest-priority task that can ever access that resource. A task executes at a priority equal to (or higher than) the priority ceiling of a shared resource as soon as it enters a critical section associated with that resource.  Applying the Priority Ceiling Protocol Emulation to the Priority Ceiling Protocol example results in the following sequence:

Levels of immersion in VR systems

In a virtual environment system a computer generates sensory impressions that are delivered to the human senses. The type and the quality of these impressions determine the level of immersion and the feeling of presence in VR. Ideally the high-resolution, high-quality and consistent over all the displays, information should be presented to all of the user’s senses. Moreover, the environment itself should react realistically to the user’s actions. The practice, however, is very different from this ideal case. Many applications stimulate only one or a few of the senses, very often with low-quality and unsynchronized information. We can group the VR systems accordingly to the level of immersion they offer to the user.

1. Desktop VR – sometimes called Window on World (WoW) systems. This is the simplest type of virtual reality applications. It uses a conventional monitor to display the image (generally monoscopic) of the world. No other sensory output is supported.
2. Fish Tank VR – improved version of Desktop VR. These systems support head tracking and therefore improve the feeling of “of being there” thanks to the motion parallax effect. They still use a conventional monitor (very often with LCD shutter glasses for stereoscopic viewing) but generally do not support sensory output.
3. Immersive systems – the ultimate version of VR systems. They let the user totally immerse in computer generated world with the help of HMD that supports a stereoscopic view of the scene accordingly to the user’s position and orientation. These systems may be enhanced by audio, haptic and sensory interfaces.

Stateful page evaluation

In stateful page evaluation, the browser history file and additional history stored by SpoofGuard are used to evaluate the referring page. Since it is important to minimize the number of false alarms, SpoofGuard does not issue any warnings for visiting a site that is in the user’s history file. The rationale for this is that if the user is warned the first time, and decides to proceed, the user is assumed to have sufficient reason to trust the site.

Domain check :  If the domain of a page closely resembles a standard or previously visited domain, the page may be part of a spoof. Although crude, we currently compare domains by Hamming (edit) distance. For example example.com will raise the domain check if example.com is in the file of commonly spoofed sites or in the user history. Clearly, it is possible to improve our comparison algorithm by studying the way people are fooled; this is a significant direction for future work.

A related issue is that some businesses outsource some of their web operations to contractors with different domain names. This poses an interesting challenge that we believe can be addressed. However, outsourced web activity leads to false alarms in the current version of
SpoofGuard.

Referring page When a user follows a link, the browser maintains a record of the referring page. Since the typical web spoofing attack begins with an email message, a referring page from a web site where the user may have been reading email (such as Hotmail) raises
the level of suspicion. One complication associated with Hotmail, for example, is that Hotmail uses numeric IP addresses instead of symbolic host names. Therefore, when a user clicks on a link in a Hotmail message, the browser provides a numeric IP address to SpoofGuard as the referring page. In this situation, SpoofGuard uses reverse DNS to find the domain name associated with a numeric address, allowing us to identify Hotmail as the referring site.

Image-domain associations The image check described on database associating images such as corporate logos with domains.
The initial static database can be assembled using a web crawler or other tool, or it can be augmented using an individual’s browsing history. An early version of SpoofGuard used a fixed database; the current SpoofGuard implementation uses a hashed image history file.

What is Home PNA ?

Home Phoneline Networking Alliance (Home PNA) [HPNA] has standardized a technology which allows networking of devices using the existing telephone wiring of the home.

There is no need for a central control unit in the network, but each device is required to have a Home PNA adapter. Those come either in the form of PCI cards or Ethernet to Home PNA adapters, which allow connecting a standard Ethernet device to a Home PNA network, as shown in Figure 1.

Figure 1. Basic home networking with Home PNA

Home PNA Version 2.0 is designed to reach up to 300 meters between any two adapters. If the network has more than two Home PNA adapters, all of the adapters must be within 300 meters of each other. The actual distance may be longer or perhaps shorter depending on the type of wire, noise conditions and topology of the telephone wiring within the home. Theoretical maximum speed of the Home PNA technology is 10 Mbps, which is quite low compared to competing previously mentioned standards.

Video Compression Techniques

Video codecs use various compression techniques to fit a video signal into the allotted channel bandwidth. These compression
techniques can affect the resulting quality of the video in different ways. An understanding of encoding principles can help a
content provider determine what content will look best on a mobile device, and highlight some of the expected trade offs when
producing multimedia files.

Quick bandwidth reduction can be achieved by using video compression techniques such as:

1. Removing statistical redundancies
   
2. Reducing resolution size (for example, CIF ➔ QCIF)
3. Using fewer frames per second (for example, 15 fps ➔ 10 fps)

Further bandwidth reduction can be achieved by leveraging the patterns within the video data and removing redundancies. Image
compression relies on discarding information that is indiscernible to the viewer. Motion compensation provides interpolation
between frames, using less data to represent the change. The goal of a video encoder is to remove redundancies in the video
stream and to encode as little data as possible. To achieve this goal, the encoder samples the video stream in two ways:

1. In time intervals from consecutive frames (temporal domain)
   
2. Between adjacent pixels in the same frame (spatial domain)

A video decoder pieces the video stream together by reversing the encoding process. The decoder reconstructs the video stream
by adding together the pixel differences and frame differences to form a complete video.

This is an overly simplified look at compression, but it is useful to remember that a compressed video stream provides the deltas
between previously encoded data, instead of a complete representation of each frame.

AES Reconfigurable Security Primitive Efficiency

The three previous feedback implementations, feedback mode (FB), feedback mode with fault detection (FB_FD), and feedback mode with fault tolerance (FB_FT), have been considered for the definition of the whole AES security primitive. We have defined three reconfigurable modules which are the datapath, the SPC, and the SSC. An area constraint has been associated to each module as shown in Fig. 1. In this experiment, we have considered a single primitive but there is no limitation regarding that point.

The communication between the modules have been performed through three bus macro which are predefined Xilinx hard IPs. One bus macro is used to provide the fault signal between the datapath and the SSC. The two others are used between the datapath and the SPC and correspond to control signals (e.g., start, reset, done). The reconfiguration is performed by the SPC through the ICAP interface which allows for the dynamic and partial self-reconfiguration of the FPGA. Fig. 1 shows the three possible configurations. The area
overhead for the fault tolerant implementation is high compared to the two other solutions. The SPC and SSC modules are very small and remain constant for the three configurations. Their complexity is small compared to the datapath so that they represent a negligible area overhead. For this study, we have considered very simple performance and security policies which are basically based on a threshold crossing or on an attack or a fault detection. For real embedded systems, these policies might use more advanced techniques. However, the overhead costs should remain small compared to the datapath.

Fig. 1. Layout of the three configurations of the AES reconfigurable security primitive. Three modules are defined which are the datapath, the SPC, and the SSC.

Concerning the performance of such a solution, the reconfiguration time is directly related to the size of the bitstream. The full bitstream which is used at power-up represents 1415 kB and the three partial bitstreams for the FB, FB_FD, FB_FT configurations are respectively equal to 356, 356, and 463 kB. In our case, the clock of the ICAP interface is 50 MHz which leads to an average reconfiguration time around 8 ms. Each time a reconfiguration is performed there is also an overhead cost in terms of power. However, this overhead is negligible for the FPGA power core and represents an increase of around 6% for the FPGA power supply.