Breach of the Drones

When it was discovered that video feeds from U.S. Predator and Reaper unmanned drones were being hacked by insurgents in Iraq, it became evident that cybersecurity has a long way to go to become more secure. The natural reaction is to point the finger at software producers, the government, and the push for functionality over security. But it may be that a different model is needed for the software itself.

When you think of military security, if you are like me, you think of planes, tanks, guns, and bombs. If you look at a tank, you have a weapon that can withstand direct attack against some serious ammunition. It is designed to be attacked and still fulfill its mission.

Software is not designed to be attacked. It is designed to provide features and functionality, but it is seldom designed specifically to be attacked. Instead, software is designed to minimize vulnerabilities.

What would happen if software were developed as if it were a military tank? If you were to develop a design pattern for software that resembled a tank, it would obviously require a very tough exterior interface to protect the crew and equipment inside. It would require very strong encapsulation to ensure that all interfaces to the outside world are well-defined and secure.

If all software were created using such a Tank design pattern there may be a variety of predefined, standardized system utility interfaces that allow secure communication with other systems and other subsystem components. This would allow the developer to implement the Tank pattern and simply select secure interface services without having to worry about coding each one.

Do you think it is possible for a one-size-fits-all design pattern or perhaps even a framework that toughens the exterior of software so it can better withstand attacks?

Read More...

Implementing Trust Between Systems

When designing or reviewing a system, it is common to ensure that trust is established between end-users and the applications. Trust in this context means that the users are trusted because they have proven their identity, and their authority to access the application has been verified. Many times, trust between system components is overlooked. This can be a deadly sin for software design that can lead to security vulnerabilities.

When trust is not established between system components, it means that any application that has access to the network can connect to the subsystem's exposed ports. For example, consider an application that exposes port 443 for receiving XML using HTTP over SSL. You might think that this is secure, since it uses encryption; however, encryption does not guarantee trust. Any web browser or system that supports HTTP over SSL can connect to that application and send malicious XML payloads.

You may say, "But my application uses a proprietary protocol that people would not understand." Unfortunately, security by obscurity is not security at all. With enough time or inside information, an application that does not require trust of the systems that connect to it may be easily compromised.

Trust generally comes with a certain amount of overhead. Here are two ways you can establish system trust in your application. First, you can require that all clients that connect to an open port present a user name and password or a shared secret key. This approach has the lowest overhead. When using web services, this can be accomplished using WS-Security. Second, you can use asymmetric encryption for non-repudiation to ensure that only the client could have connected because only it has a public key that can decrypt the message. This approach has high overhead, since encryption requires time and system resources, but it also ensures that the credentials are not exposed in clear text.

Many companies allow so many other companies into their networks, and insiders are frequently as much of a threat as external attackers. With this in mind, firewalls have limited value and are not very good at establishing trust. They are good for building a layer of security around your applications, but this does not compensate for a listening port that does not require trust.

How are your applications doing at establishing trust?

Read More...

Cybersecurity in 2010: Bubble or Blip?

Take a look at Google trends for the word "cybersecurity", and see what you find. In the third quarter of 2008, there were two small blips on the radar for this search term. In 2009 there was a sharp rise throughout the year. What will 2010 look like for cybersecurity, and are we at the beginning of a cybersecurity bubble?

The Internet bubble was driven primarily by new web technologies and the potential for rapid profit. Cybersecurity, at present, is driven by regulatory compliance and government initiatives. It is unrealistic that this will be a bubble of the magnitude of the Internet bubble, but here are a few interesting parallels.

First, there are currently plans to hire up to 1,000 cyber security professionals by the Department of Homeland Security. This is in addition to the hiring of contractors that serve the government. During the Internet bubble, it was very difficult to obtain quality technical personnel. They were snatched up quickly, and the rates skyrocketed.

Second, there is the potential for the development of new security technologies. Research universities, working with Northrop Grumman, will be exploring new technologies to provide better security. This may trigger the development of new products from existing and new vendors. This also parallels the Internet bubble.

Third, regulatory requirements related to security continue to increase, putting more pressure on companies to improve their information security operations. This gives rise not only to personnel who implement the compliance programs, but also to consultants and auditors.

What will 2010 look like? My prediction is that cybersecurity professionals will be in high demand, making staffing them especially challenging. As boards and CEOs take an increasing interest in security, new companies will enter the security technology market, and this will create even more strain on the talent pool.

What should you do? If you are a cybersecurity professional, keep your skills honed, certifications up-to-date, and finish your degree. There is great opportunity ahead. If you are not experienced in cybersecurity, keep an eye on companies that rise to the challenges of the new year and consider investing in those that have the most potential.

What do you think? Will the rise in cybersecurity be a bubble or a blip?

Read More...

Cybersecurity Government Job Fair

With the increasing attention to cybersecurity in the government sector and in critical infrastructure protection, the Department of Homeland Security announced in October that it would be hiring for as many as 1,000 cybersecurity jobs. DHS is moving forward on that promise with a virtual job fair.

The job fair can be accessed at http://www.dhs.gov/xabout/careers/cyberjobfair, and it works like a typical job board. There are currently 12 jobs posted, but it appears as though these are job titles, and that there are many positions to fill for each.

There are three different job titles, but each is available in four different pay grades, ranging from GS 12 through GS 15. This translate to salary ranges from $73K - $153K. The four titles are: Information Technology Specialist (Cyber Security); Intelligence Research Specialist (Cyber Security); and Security Specialist.

This comes at a time when the US and Russia are actively talking about limiting military use of cyberspace and strengthening Internet security (NY Times).

This is good news for the career outlook for security professionals. Will this become a security bubble?

Read More...

On-the-fly Encryption with TrueCrypt

How sensitive is your data? You may use highly confidential data at work or at home. If you are concerned about the potential exposure of that data, encryption may be a good solution for ensuring that your data remains protected. One tool that you can use to encrypt your data is TrueCrypt. It is a free, open source program that works on Windows 7/Vista/XP, Mac OS X, and Linux.

TrueCrypt is a very easy-to-use tool. I installed it today on my Ubuntu laptop, and within about five minutes, I created an encrypted drive and put sample data in that drive. You can download the software at http://www.truecrypt.org/.

When you create an encrypted drive with TrueCrypt, you are creating a file on your file system that contains all of the encrypted data you will be protecting. Creating the encrypted drive is the trickiest part, but the on-line tutorial for beginners makes it very easy to use. If you are more experienced with encryption technologies, you may like that it offers a variety of algorithms, including my favorites - AES and SHA-256.

After you create your encrypted drive, the next step is to mount it. To do this, you select a drive letter (Windows) or a slot (Linux) to which to mount the drive. Next you select the encryption file you just created and mount it. You will be prompted for the password for the encrypted drive that you entered when you created it. If you enter the correct password, the drive mounts, and you can use it like any other drive or file system.

In Ubuntu, from the Settings / Preferences window, I chose to use automatically open the mounted drive in Explorer once it was mounted, so a normal file system window popped up and allowed me to use it like any other mounted partition. I was also able to find the mounted partition in /media/truecrypt1, which allowed me to use it from the command line as well.

From what I have seen, the Windows version has some added functionality for encrypting system partitions and even creating a hidden encrypted partition that can be used for creating a hidden operating system. This may be good if you are trying to cover your tracks, but from a security professional's view, this may be hard to detect in a forensic investigation. Perhaps in a future post, I will try to find a hidden TrueCrypt system partition using FTK or Encase.

Have you used TrueCrypt? What do you think of it?

Read More...

Spinning Out of Control: Securely Managing Virtual Sprawl

Server virtualization is taking hold. It boasts so many advantages that it is likely to become the standard for data centers around the world. It saves money by maximizing hardware resources. It reduces the number of physical servers, which reduces power consumption. It also revolutionizes server deployment by allowing servers to be copied as easily as files on the file system. Add to this the benefit of using pre-configured virtual appliances, and you should be convinced that virtual servers are good for your business.

As with any new technology, security tends to be an afterthought. Many companies that venture into virtual technologies expect that their existing security controls will apply to the new virtual environment, but virtual servers require new security approaches and controls.

In an IT department with weak or missing security controls, virtual servers will sprawl across physical hardware and quickly become unmanageable and vulnerable to attack. To jump into virtualization, it’s essential to be innovative about security and to reinvent your security controls.

Segmentation
In the physical server environment, there is some level of built-in segmentation of applications and data. They are divided by networks, and administrative privileges may be separated at the server level. Some data centers even segment their physical servers with separate rooms that require specific authorization for physical access.

Virtual servers may be operating on the same servers, logical disks, and even CPUs. In the past, physical segmentation did not require significant planning. It was more of a natural security control.

Before deploying your virtual server environment, think through how you will segment your virtual machines to compensate for the loss of physical segmentation. If you must comply with standards that require classification of critical cyber assets, you will need to spend more time to ensure that you are not commingling critical and non-critical assets on the same physical host.

Patch Management
Many companies already struggle with patch management. Virtualization will amplify the problem by making it easier to deploy servers and more challenging to patch them. If the interdependencies of applications and the lack of testing personnel hinder your patch management today, remember that virtualization will add another layer of dependencies. Now a single patch may affect more servers, more applications, and more data.

To patch virtual servers, make sure that you have policies, standards, and procedures that define acceptable practices for patching virtual servers. This should include the definition of acceptable network segments for applying patches and hardening standards for host operating systems.
Follow up with routine network vulnerability scans to report on the effectiveness of your patch management procedures. Remember that even your vulnerability assessments may need to change to accommodate specialized virtualization host operating systems, such as VMWare ESX. You may also need to redefine the severity of identified vulnerabilities to increase the priority of those found in host operating systems and hypervisors.

Server Life Cycle Management
Traditional server life cycles define the deployment, on-going operation, decommissioning, and clearing of servers. This requires good asset management controls. These controls will need to be modified to reflect the ease of copying and redeploying existing virtual servers.

Like patch management, you will need to take a close look at your policies related to the deployment, decommissioning, and clearing of servers. Establishing standards will help, but you will also need to look at asset management solutions that automate tracking of virtual assets.

Some solutions tag virtual machines and only allow authorized virtual servers to start up on a given physical host. This will help ensure that rogue devices are not started up without going through proper configuration management procedures.

Security Monitoring
If you are currently monitoring network traffic using an intrusion detection system (IDS), you may need to rethink your security monitoring strategy. Depending on the configuration, your virtual machines may be able to communicate with each other without traversing the network, which will make it impossible to monitor using a traditional IDS.

To begin with, make sure that virtual servers are not hidden behind a network address translation (NAT) scheme that prevents your IDS from distinguishing activity between virtual servers. It may require routine auditing of hypervisor configuration to ensure that each VM receives its own IP address. Also look for opportunities to deploy virtual IDS appliances on the physical servers to monitor inter-VM traffic.

Consider using your IDS to track the virtual server life cycle. This will allow you to detect when a new VM is spun up and to ensure that it is authorized on the network.

Conclusion
When jumping into server virtualization, make sure you first consider how you will need to change your practices to prevent server sprawl and security issues. Proceed with caution, and you can benefit from virtual technologies without adversely affecting your business.

Read More...

Virtualization: Red Pill or Blue?

Virtualization technologies have been compared to the movie, The Matrix. In this, Neo and other humans, are captured in a virtual world. Neo is offered a blue pill or a red pill. The blue pill will return him to his normal unreal world in the matrix. The red will set his mind free by exposing the matrix. When it comes to virtualization technologies, the red pill and blue pill have similar meanings.

Red Pill
The red pill is a small piece of code that, when run on a virtual machine, is able to determine if it is running in a virtual system or a real, physical system. It does this by detecting if the operating system is under the control of a hypervisor, the monitoring process that enables virtualization.

Theoretically, programs operating in a virtual instance should not be able to determine anything outside of the virtual instance. This encapsulation is important to ensure that the operating system operates independently.

The red pill is more than a theory. A few lines of C code are all that are needed to create the red pill code. The following sample was developed by Joanna Rutkowska:

int swallow_redpill () {
  unsigned char m[2+4], rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
  *((unsigned*)&rpill[3]) = (unsigned)m;
  ((void(*)())&rpill)();
  return (m[5]>0xd0) ? 1 : 0;
}

More details about how Rutkowska's red pill works can be found at: http://invisiblethings.org/papers/redpill.html

Blue Pill
The blue pill takes the concept of the red pill further to create an exploit using virtualization. The most popular example of this was also developed by Joanna Rutkowska. The blue pill uses virtualization capabilities built into some microprocessors to trap the computer's operating system into a virtual machine. The blue pill acts as the hypervisor and has complete control of the regular operating system, now trapped in the virtual machine.

Rutkowska's blue pill is said to be completely undetectable, although some have disputed this claim. Whether detectable or not, it is a demonstration of one type of exploit made possible by virtualization technologies.

Bottom Line
The bottom line in this discussion of the red and blue pills is that virtualization technologies may become exploitable. This may allow an attacker to gain access to virtual servers or create an undetectable root kit. If you are using virtualization, stay on top of vulnerabilities in your software and patch regularly.

Read More...

Patch Management In a Virtual World

As more and more companies adopt virtualization in their data centers to reduce the number of physical servers and save money, security strategies need to be developed in parallel. While security may push back on this movement and resist its adoption, it will be far more beneficial to develop security strategies to deal effectively with advancing virtualization technologies.

Patch management is one area that is especially important in virtualization. While the ability to save a virtual machine and copy it easily to other physical servers streamlines deployment, it can lead to outdated software that is vulnerable for exploitation. In addition, the ability to suspend a virtual machine in its current state means that a suspended instance may be activated in a vulnerable state if patches have not been applied.

Here are a few patch management considerations when securing virtual hosts:

1. Keep the host operating system patched and hardened
Securing the host operating system is essential in virtualization. If everything works as it should, virtual machines should not be aware of their own virualization or of other virtual instances on the same physical server. This encapsulation is provided by the host operating system. Unpatched vulnerabilities in the host operating system may lead to the compromise of all of the virtual instances. Keep alert for security patches in the host operating system and have a strategy to quickly apply them.

2. Activate virtual machines securely
When deploying a virtual machine, make sure that it is fully patched before connecting to your production network. This may be accomplished by using isolated network segments where virtual instances can be activated and patched before moving them to a production environment. You may also want to consider network access control products that detect the patch levels and antivirus capabilities of new devices and restrict network access until they are patched.

3. Scan for vulnerabilities
Make sure that your regular vulnerability scans are aware of and have network access to virtual machines. Patch management is a preventive control, but many organizations struggle to keep up-to-date, so network scanning is a detective control to assess and respond to unpatched physical and virtual servers.

4. Establish policies, standards, and procedures
Make sure your policies and standards address the patch management of physical and virtual machines, server hardening, and network locations suitable for patching and deployment. If communicated and enforced effectively, these will help ensure consistency and repeatability of patch management.

5. Watch for third-party supporting products
Virtualization vendors typically do not have comprehensive solutions that address the security management aspects of their products. Keep on the look out for new products as this technology matures. A system that includes patch management and security solutions from multiple vendors may provide defense in-depth and help assure the security of your virtual environment.

What are your strategies for secure patch management in your virtual environment? What supporting products are you using? Please share your feedback in the comments section.

Read More...

Six Sigma for Security, Part 5: Staying in Control

After you have moved through the define, measure, analyze, and improve stages of your Six Sigma for Security project, you are ready to move into the control phase. Your security operations should always operate in the control phase. If so, the control phase for Six Sigma is merely a matter of adding your improvements into your existing controls.

Here are some tools that you may find helpful in the control phase:

• Control matrices
• CTQ dashboards
• Control charts
• Performance graphs

The more of your metrics you can automate, the more successful you will be in the control phase. If you have to spend time every week or every month to pull data, manipulate it, and report on it, you will quickly stop measuring. Use Excel and Access extensively to make routine measurement and reporting a snap.

The control phase does not use the detailed analysis tools used earlier in the Six Sigma project. It only reports on the results. If you find that you are no longer meeting your targets in any CTQ goal, go back through the Six Sigma process again to see what caused the change. You may have something influencing the process causing variation, or the quantity of work may require you to re-examine resource allocation.

Have you made it this far through the Six Sigma for Security process? How has it worked for you?

Read More...

Six Sigma for Security, Part 4: Making Improvements

You have made your security program measurable. You have identified problem areas that keep you from meeting targets in your critical to quality (CTQ) goals. Now it is time to move on to making improvements and measuring their effectiveness.

One of the great things about Six Sigma is that improvements are tied to specific metrics, with a goal to reduce variation and improve your average. To make this work, continue with your CTQ goals, tied to root causes for problems within those goals. Each improvement project should be tied to these root causes. This is the first stage of the project in which you get to look at solutions.

One of the easiest ways to identify the best improvement opportunities is brainstorming. For each root cause problem, work with a team to list as many solutions as possible. They don't have to be practical or affordable. Your goal is to find as many creative solutions as possible. When working with a team, ask the team not to place any value judgment on any of the solutions. Instead, rapidly throw out ideas and keep moving.

Next rank each improvement idea in each root cause area according to the following attributes, such as on a scale from 1 to 4:

• Ease - Rate each improvement on how easy it is to implement. You are looking for quick wins.
• Impact - Rate the likeliness of the solution solving the root cause problem. You may find good solutions, but they may not be for the problems you are trying to address. Make sure you are tying it to the root cause.
• Affordability - Rate how affordable this solution is.

Multiply the above factors together to create a score for each improvement idea. The top scores are your best choices to make measurable improvements. They combine positive impact with ease of implementation and affordability. By tackling improvement ideas starting with the highest score, you can use your limited resources in the most effective way.

After implementing each improvement, measure again and see if your CTQ metrics have improved. If they have improved dramatically, congratulations. You have found the best solution. If they have improved slightly, try moving down your list of improvements to see if the next solution will help.

It is important to note that not every idea on your improvement list should be implemented. Only the top scoring ideas. The other ideas have less impact, take too long, or are too expensive. After trying your top improvement ideas, discard your list and start over to find valuable solutions.

Finding the best, measurable improvement opportunities for security management departments is important. Companies keep security lean. Six Sigma for Security will help you to make the best use of your time and resources.

Read More...

Six Sigma for Security, Part 3: Analyzing the Data

Making security measurable is only the beginning of Six Sigma for Security. The purpose of security metrics is not the metrics themselves but what you do with them. The next phase is to analyze the data and find opportunities for improvement.

The analysis phase is what makes Six Sigma stand out. In it you will use statistics to find where you can make improvements. There are two improvements in your measurements that are important: 1) average performance; and 2) variation.

Your average performance is an important measurement because it allows you to track and trend how well you are doing at protecting information assets. But performance may vary widely around an average. For example if your average turn around on a user termination is 15 days, it may be that half of your requests are 30 days. Some may even linger for 90 days. This is very wide variation around the 15 day average.

Your goal in the analysis phase is to quantify variation and identify factors that can positively influence your performance. This is accomplished by using a variety of statistical analysis tools.

One of the most popular and easy-to-use tools is Pareto analysis, which allows you to quickly find the biggest problem areas in your metrics. It also results in a distinctive chart that shows you frequency and a cumulative percentage to visually quantify the impact of improvements.

Analysis is one of the most challenging phases of Six Sigma. Until now the process has been very consistent and predictable. In this phase, you may try analyzing data one way, find nothing worthwhile, and try it again in several different ways. It is a trial and error process in which you don't stop until you find something of significance that can lead to improvement.

At the end of the analysis phase you should end up with root causes for problem areas in your security metrics. If you are confident that you have arrived at the root cause, you are ready to move on to the improvement phase.

Learn more about Six Sigma tools on Wikipedia.

Read More...

Six Sigma for Security, Part 2: Measuring

After you have defined the Critical to Quality (CTQ) goals of your security program, the next step is to determine how to measure them. Creating a measurement plan for security is like creating a scoreboard. It allows you to gauge at any time how successful you are and your level of protection.

Keep in mind that at the outset of this Six Sigma project we determined that we would not just measure the results of security, which should be few and far between. Instead, we are focusing on measuring the level of protection.

In the measurement phase, we take the four CTQ goals and create a measurement plan for each. Here are sample metrics you may decide to capture.

Policy

• Annual review/approval of policy completed
• Percentage of policies with corresponding controls
• Number of policy exceptions documented
  

Process

• Percentage of controls followed as scheduled
• User access management SLAs
• Incident response times

Partnerships

• Number of security awareness sessions completed
• Number of monthly cross-department meetings completed
• Number of customer contacts made

Payoff

• Internal policy violations
• Security incidents resulting in loss
• Virus/malware incidents
• Compliance gaps

These measurements should get you started. To determine your measurements, brainstorm to create a list of everything that would be nice to measure. Then decide which three or four are the essential metrics. If you have more than three or four measurements for each CTQ, you will quickly be overwhelmed with data.

The next step in building your measurement plan is to identify the data source for each of the metrics. You may find that you don't have a good source of data for some. In these cases, consider ways to begin capturing it now. You may simply use a data collection worksheet to keep track. Keep it simple, but automate it whenever possible.

With your CTQ goals defined, your metrics for each determined, and your data sources identified, you are ready to begin collecting data. For some measurements, you will be able to retrieve historical data and begin your analysis immediately. For new data sources, you may need to capture data for a month or two before you have enough information for analysis.

Complete your measurement plan and capture data as soon as possible. This should be the quickest phase of the Six Sigma for Security project. It will establish a baseline that allows you to set your goals for improvement. It will also allow you to move into one of the most interesting phases -- analysis.

What are some of the metrics you are using to keep score for your CTQ goals?

Read More...

Six Sigma for Security, Part 1: Defining Success

How do you measure the effectiveness of your security program? Unlike business metrics which have tangible goals, such as revenue growth, inventory reduction, and sales force effectiveness, security's goal is to prevent internal and external breaches. Your goal in security should be to have nothing to measure - no virus attacks, no external breaches, no successful social engineering attacks, no insider exploits.

Although measurement of security incidents and related losses has value, it is not sufficient for measurement of security effectiveness or for justifying the cost of security investment. It is important to have a different standard for making security measurable.

Instead of measuring loss, this article proposes measuring prevention. Security management changes over time, but it is generally accepted to consist of a set of best practices for prevention of business loss caused by security breaches. If you do well at following the standards established by ISO27001, ITIL, ISM3, or CoBIT, you will have exercised due care and will have have provided excellent protection for your information.

But how do you know how well you are doing in following these standards? This is where Six Sigma comes in. Six Sigma is an improvement process that is commonly used in manufacturing. In recent years it has been applied to various types of businesses. The goal of Six Sigma is to define how to measure success, measure the current performance, analyze the data to find root causes of problems, implement improvement projects and test their effectiveness, and move newly implemented processes and practices into a controlled phase. To remember this project life cycle, the acronym DMAIC is used. It stands for:

• Define
• Measure
• Analyze
• Improve
• Control

Applying Six Sigma to security management means walking through the DMAIC process. The most critical stage is the Define stage, where the Critical to Quality (CTQ) goals are defined. These goals are carried through the process and are used to measure success. For most uses of Six Sigma, CTQ goals are defined by finding the voice of the customer. In security management, because of the growing body of knowledge and best practices, they are easier to define.

Consider these four CTQ goals for measuring your security program. They are especially geared toward measuring how well you are performing standard best practices in security management.

1. Policy - Measuring the quality and enforceability of your security policies
2. Processes - Measuring how well you follow defined practices according to the standards you adopt
3. Partnerships - Measuring your efforts to build relationships with other departments and customers
4. Payoff - Measuring incidents and resulting business loss

With the CTQ goals of security defined, the next step is to create a plan for measuring them and begin capturing this data.

These CTQ goals for security are generic. Do they work for your security organization? Please share your comments.

Read More...

Privacy on the Web, Part 4: How to Hide from Web Beacons

Why would I want to hide from web beacons and consolidated web traffic analysis? I don't have anything to hide. We each make decisions about how much privacy and security to give up to gain convenience. The settings in web browsers - to save passwords, accept third party cookies, and keep authenticated sessions persistent over many days and across many sites - make using the web easier. For some people this is an acceptable trade off. For others it is a more serious matter.

You may want to consider some privacy measures if you are:

• A regular user who wants to keep your web browsing habits out of the hands of marketers
• A parent who wants additional protection for your children online by hiding their IP address
• A member of the military or are involved in covert activities
• A citizen in a country that monitors the web and enforces information standards
• A whistle blower who wants to remain anonymous
  
• A journalist, writer, or blogger who publishes sensitive information
• An activist concerned about privacy
  

At the most basic level, hiding from web beacons is as easy as turning off cookies in your web browser. Unfortunately, many web sites won't work if you do not enable cookies. You can limit the exposure of your web browsing by clearing your cookies frequently, such as each time you close your web browser. This segments the trail of information about your web surfing habits and makes your browsing less identifiable across web sites and over a period of time.

This approach only helps to reduce your exposure to web beacons. It does not protect the normal web traffic that is part of the HTTP protocol. HTTP traffic is the network information that passes from your web browser, over the Internet, to a web server, and back again. It is what makes the web work. Each request contains your IP address and the page you are requesting. It also contains the web address of the web site you visited, if you clicked on a link to get there.

If you are really serious about web privacy and feel that you need to hide from web beacons and HTTP traffic analysis, you need a complete solution that bounces your web traffic off of several relays and manages cookies. One solution for this is Tor and Privoxy.

Tor is short for "The Onion Router". It uses relays distributed across the Internet to hide your HTTP traffic from the web sites you visit. When configured correctly, it provides a high degree of privacy on the web. It does not, however, provide protection from web beacons, which run from the content of the web pages, usually using Javascript.

Privoxy provides a flexible solution for handling of cookies and blocking various types of content. When used with Tor, it provides the content-level privacy from web beacons.

Both Tor and Privoxy are freely available, but they may require some time to learn and configure correctly. There are also commercial solutions available that may simplify the setup and configuration.

How much web anonymity is right for you? You need to decide the right balance of convenience and privacy for yourself. When writing this series of posts, I tried some of the measures described here, but found that I'm more in favor of convenience. I have gone back to allowing cookies, web beacons, and HTTP traffic that can be traced to me.

How much privacy is right for you? Please share your thoughts in the comments section.

Read More...

Privacy on the Web, Part 3: Analytics, Recommendations, Summarizing, and Anonymity

Since web beacons from outsourcing companies may be able to track your every move, you may wonder what they are doing with your information. This post discusses the positive side of collecting and using this information. It also touches on the issue of anonymity and privacy.

Analytics
If you are running a web site today, you are probably using some form of web analytics. From the multi-billion dollar retailer to the blogger who publishes his rants, web analytics are easy to implement and provide a gold mine of information about your visitors. For this web site, I use a web beacon (some Javascript provided by a major analytics company) to collect traffic data to answer questions like:

• What is the most popular content?
• How did users get to the web site?
• What keywords were used in search engines to get to the site?
• What was the most used landing page?
• How many pages per visit did users view?

Analytics, when used locally by a web site publisher, allow the publisher to enhance content and better reach an audience. For the web publisher, using the web beacon approach to gather these metrics is not only the easiest, it is also the most accurate approach. This is because legitimate web indexing services crawl web sites regularly and inflate traffic data. Web beacons that use Javascript do not record this data, since the indexing services do not execute Javascript.

Analytic data is summarized data. Although the raw data contains information about individuals and their behaviors on the web, companies who use the data aggregate it and use it to draw conclusions about all users -- not individuals.

Recommendations
Companies use data collected from web beacons to feed their recommendation engines. This along with other sources of data helps them to present products that you may be interested in. Some recommendation engines will use the data to group users into virtual communities of people with the same interests, which broadens their ability by recommending products that others in your community are buying. Recommendations work with data at the individual level, but for this use, companies don't view the data.

Recommendation data is information about the individual user. An automated process works with the data to identify you personally and serve you recommendations. The user's web behavior is probably never reviewed by people, unless someone is debugging problems with the recommendation engine.

Targeting the Individual
Some web beacons collect information that you have submitted to the web site you are viewing. This may include your email address, user name, or account number. Companies may use this to follow up. After identifying you personally, you may be tracked to see what you purchased. The company may follow up with you individually or use this information for targeted email marketing.

Crossing the Boundaries
None of this may seem out of line to you. Most organizations that use web beacons to collect information about you have no harmful intent but rather aim to make your experience better. The potential issue lies with the collection of this data by large companies that cross company boundaries. Because they are a common collection point, they have the ability to match data from multiple web sites.

One privacy issue is that the privacy policy of the web site you visit may not be honored by the web beacon data collection company. This information may be provided to third parties or used in ways in which you have not agreed.

Another privacy issue is that this creates more repositories of rich user data that may or may not be protected with adequate security controls. It is subject to insider threats and may be used for corporate espionage and unsolicited email.

What do you think about the collection of web behavioral data that crosses web sites? Does it threaten your privacy?

Read More...

Privacy on the Web, Part 2: How Beacons Work

Web beacons are snippets of Javascript or HTML that create one pixel by one pixel image requests to a different web site that collects the data. This single pixel is invisible to the viewer of the web site. It is usually placed just inside the closing "body" tag of the page, although some analytics companies recommend that it be placed inside the opening "body" tag to improve accuracy.

There are three types of information that are collected using this image:

1. Data embedded in the URL: At a minimum, this data includes some form of account ID that represents the publisher of the web site the user is viewing. It may include any variables that can be retrieved using Javascript, such as screen resolution. It may include custom variables that better identify the user, such as user account number, email address, and any other data that the web site publisher collects from you during your visit.

2. Normal HTTP Data: This is collected by the web server that hosts the the one-by-one pixel image. This includes IP address, date and time, the page you requested, the previous page you requested, browser type and version, and session ID.

3. Persistent Data: This is collected in session cookies to to track your navigation through the web site you are viewing and in persistent cookies that connect your information between visits, and most interestingly, from other sites.

The company that collects the information that was embedded in the one-by-one pixel image stores raw data for each pixel request it receives. The company may provide tools for advertisers and customers using web analytics to aggregate data, graph it, display it in tables, and create custom reports. The output of this may be used to test marketing strategies, improve site navigation, or report on the success of a campaign. Companies will usually export the data and use it in recommendation engines.

Want to see it in more detail? Here are two things you can try. Go to the web site of a major retailer. From your web browser, view the source of the page. Scroll down to the bottom, near the "body" tag. Look for comments or snippets of Javascript that may be a web beacon. If it is just an image tag, try its URL in your web browser to see if it is an invisible 1x1 image. If you want to see some real action, try the Tamper Data plugin for Firefox. You can inspect the requests made by your web browser and identify requests that are not for the site you are visiting.

The important thing to note is that in order to track users across web sites, the companies that provide advertising or analytic services must use a persistent cookie and it must be generated by their own domain. If publishers and retailers use their domain for the cookie, the cross-site tracking will not work.

Read More...

Privacy on the Web, Part 1: The Beacons Know You

Did you ever notice how a web site you have never visited before knows your interests enough to give you targeted advertisements? Sometimes, the ads are based on the content of the site, but other times, there appears to be no connection. There is an approach to collecting user information that crosses web site boundaries and maintains a history of your preferences.

You may ask, how is this possible? Are these companies sharing information? Is there adware on my computer that's giving out this information? No. The answer is much simpler -- outsourced advertising and analytics.

Many companies can't afford to maintain a department that attracts advertisers, manages advertising sales, and tracks ad performance. As a result, they outsource their advertising to a specialized company. In the same way, most companies do not have the tools or expertise to track their own web site metrics, so they outsource to large companies that specialize in web analytics.

To display appropriate advertising, track ad performance, and track overall behavioral metrics on web sites, these companies that provide the service require the publisher or advertiser to put a small piece of code on their web site. This may be a small piece of Javascript or a simple image request. It is this image request that allows the advertising or analytics company to track user behavior across multiple web sites, since they are provided information about you at each site that has their beacon.

This week's posts will describe web beacons and your privacy in more detail. They will explain:

• How Beacons Work
• Analytics, Recommendations, Summarizing, and Anonymity
• How to Hide from Web Beacons

Now that you know, do you mind that these companies can track your behavior across web sites? Post your comments below.

Read More...

Security Process Maturity: Level 5

Security managers are often plagued by the question, “How do I make security measurable?” Since security does not produce a product or have a positive impact on the cash flow of a company, creating meaningful measurements that justify an organizations expenditure on security is challenging. This is where ISM³ provides a great tool for measuring security.

ISM³'s level five is about taking all of the processes of levels one through four and using them to communicate the coverage and effectiveness of security.

ISM³ defines seven types of metrics that work well within this maturity model:

Process Metrics

• Number of times a security process was performed in a period
• Scope of protection as a percentage of assets protected by the process
• Time since the last update of process outputs
• The time since a security process has produced the expected output

Performance Metrics

• Return on Security Investment (ROSI) as the percentage of losses avoided compared to the cost of the process
• Comparison of the process output to a baseline or benchmark
• Ratio of available resources in actual use

Measuring each of the ISM³ processes implies that there is a system that easily captures metrics as part of normal operation. Without a centralized metrics reporting system, ISM³ level five will be unsustainable.

The most important reason for measuring your security processes is to identify how well you are operating and work on continuous improvement. At this level, managing the process of continuous improvement is important. By measuring, automating, improving, and communicating your security metrics, you will create a sustainable, continuously improving security operation.

Read More...

Security Process Maturity: Level 4

Level four of ISM³ adds the remaining security processes in the model. This level requires the highest investment, but provides the highest level of protection against technical and internal threats. The security processes in this level are necessary if your organization operates in a highly regulated environments with information assets that are targets for attackers. Examples include stock exchanges, financial institutions, and utilities.

The operational security processes for level 4 are:

• Enhanced reliability and availability management
• Information archiving
• Information quality and compliance probing
• Events detection and analysis
• Forensics

If level four fills in the remaining security processes, what's left for level five? Tomorrow's post will move us from managing security processes to measuring and continuously improving them.

Read More...

Security Process Maturity: Level 3

The third level of ISM³ requires significant investment, but it provides a high level of protection against technical security threats. This level is important for organizations that have high security risks and many critical assets, especially externally facing applications.

The jump from level two to level three does not add many processes, but the processes require more people and time commitment. In addition, these processes require more participation from business function owners, IT operations, project management, and software development. To achieve this level, your security staff will need skills to create a collaborative, participative environment.

The level three operational security processes are:

• Asset classification and management
• SDLC control
• Operations continuity management
• Incident response
• Incident emulation

The level 3 processes build on the previous levels. Building a solid foundation at levels one and two before tackling level 3 will provide broad security coverage of systems, processes, and people.

Read More...

Security Process Maturity: Level 2

For most businesses, level one will not provide enough security to protect their information assets. If a company needs to demonstrate due care to its business partners, has many users of server-based applications, and sensitive information, it needs to move up to the security processes listed in ISM³'s second level.

Level two provides additional protection against technical security threats. It requires more security investment, but not significantly higher. The processes in level two build on the level one processes. To achieve this level, you will need to define and manage all of the level one and level two tasks.

The level one processes may be able to be accomplished by IT technical staff, but level two requires a combination of dedicated security professionals and facilitation with IT departments responsible for server and application administration.

The operational security processes for level two are:

• Select security tools
• Environment change control
• Data clearing
• System hardening
• Security measures change control
• Access control
• User registration
• Physical security
• Internal technical audit
• Alerts monitoring

Level 2 security is a good starting point for securing your organization, but it may not meed compliance standards, such as SAS70, SOX 404, PCI, and NERC-CIP. If you are required to comply with these standards, you'll need to move up to level 3 or 4.

Read More...

Security Process Maturity: Level 1

How mature is security in your organization? Thanks to the ISM³ Consortium, we have a framework for measuring the security maturity of any organization. ISM³ looks at security as a set of defined processes. Each level of maturity has its own processes. Organizations can decide how much security is enough for their type of business and ensure that the processes at that level are defined and implemented.

This series provides a high level view of the operational processes of ISM³. Learn more about ISM³ and its strategic and tactical processes at http://www.ism3.com.

Level one security is suitable for organizations that have very low risk of security threats. These companies have few or no servers and operate primarily using personal computers. At this level, the operational security processes require little investment yet reduce the risk of security threats.

The operational processes for level one are:

• Patch management
• Segmentation and filtering
• Malware protection
• Backup management
• Reporting to tactical management

These processes may be performed by existing IT operations personnel and do not require a dedicated security staff.

Read More...

Secure Coding Practices, Part 11: The Checklist

This post wraps up the series on secure coding practices. Remember that secure coding begins with having coding standards that are communicated to software engineers. Awareness of the secure coding practices alone will help improve the security of your software applications.

Next, remember that source code must be reviewed. This practice may be performed by software engineers, by a security analyst, or both. Any violation of secure coding practices should be noted and tracked for follow up. Consider tracking these vulnerabilities in your defect tracking system to ensure they are addressed.

Please feel free to use the Red Light Security secure code checklist, "Fifty Questions to Improve Software Security", as a guide to get started. It summarizes all of the questions found in the posts of this series.

Read More...

Secure Coding Practices, Part 10: Code Quality

Overall code quality is important for secure applications. Software bugs may create opportunities for attackers to exploit the application or gain information they should not have about system internals or even user credentials.

Security professionals may not know enough about the code they review to understand what is a defect and potential vulnerability. Some developers also overlook coding problems. This is why automated static analysis of source code is so important. Although it does not replace manual review, it is an excellent supplement to help find problems.

Keep in mind that these automated tools generally find a lot of defects that are not actually defects. Each warning created by these tools needs to be looked at and qualified before raising them as issues.

Below is a brief summary of some code review tools that are specifically geared for security. Try using different tools for the same code. It may help you find more defects.

Software	Java	C/C++	Perl	Python	Comments
Commercial
Fortify SCA					Lots of other languages
Ounce					Also .Net, C#, ASP
Free Software
FindBugs					Excellent choice
Lint4J					Good choice
RATS

Do you have other tools that work well for you to find security vulnerabilities in source code? Please share them in the comments section.

Read More...

Secure Coding Practices, Part 9: Performance

One of the security professional's concerns is the availability of systems. Although this may seem like the sole responsibility of the IT operations department, security assesses the risk to the availability of critical information assets. This is because attackers may not care about retrieving information or gaining access to your systems. They may simply want to attack your system to make it unavailable for normal use.

The most common term for this type of attack is Denial of Service (DoS). A DoS attack may be intentional or be caused by misconfiguration of another system. As a result, applications must be able to perform well under stressful operation.

Performance factors vary widely depending on the server, operating system, third party software, and software languages.

When reviewing source code, ask these questions to help uncover potential performance problems:

• Is the application thread-safe?
• Are variables encapsulated to limit their scope and prevent sharing between processes?
• Are efficient algorithms used?
• Are database transactions clearly defined and not subject to deadlocks?
• Are database tables indexed appropriately?
• Are file handles and connections to external systems explicitly closed?
• Are all variables that are initialized actually used?
  

It is better to find potential performance problems before there is a production outage, so that you can look at the source code thoroughly and objectively.

Read More...

Secure Coding Practices, Part 8: Cryptography

Several volumes can be written on encryption. With the various protocols and and approaches to encryption, it can leave software developers uncertain about how it applies to them.

Sensitive data must be encrypted. This may be to support compliance requirements, such as PCI and HIPAA, or it may be because your own organization has standards that require certain data to be encrypted. At a minimum, user credentials, like passwords, must be encrypted.

Data can exist in three different states: 1) at rest, meaning it's stored in a file system, database, or archive media; 2) in transit, meaning it is moving from one system to another system or subsystem (usually over a network); and 3) in process, meaning it is being processed by an application and may be resident in memory or the CPU's registers. It is data at rest and data in transit that should be considered for encryption.

In some cases, the transport layer may be used to allow encryption over a network The applications that receive this data will not need to decrypt the message. This means that data that is being stored will not be encrypted, unless the application storing the data or the storage layer itself performs the encryption. Examples of transport layer encryption are SSL, TLS, and IPSec.

In other cases, encryption may be performed by the application, which means that the data can be sent across an unencrypted network, because it leaves the application encrypted. It also means that data can be stored directly on the file system or in a database, because the data is already encrypted.

When looking at encryption, make sure your encryption protocol is sufficiently strong. The increasing performance of computers makes decrypting much easier for attackers. Consider protocols such as AES, 3DES, and TLS for starters.

When writing or reviewing secure code, the following questions are important:

• What is the sensitivity of the data being processed by the application?
• Is encryption required for the data? If so, in transit, at rest, or both?
• Does the application comply with your organization's standards regarding encryption?
• Are standard, accepted encryption protocols being used, rather than home-grown algorithms?
• Are passwords encrypted in transit and at rest?
• Are keys used with encryption protocols managed securely in the application?

Encryption is essential for certain information, but performance is also important. Make sure your application encrypts only what is needed to ensure optimal performance.

Read More...

Secure Coding Practices, Part 7: Error Handling

Error handling is important in software applications. For developers, it may be a necessary evil, but for security professionals, it is a vital part of maintaining confidentiality, integrity, and availability. Error handling, tied with appropriate logging, is also important for investigation of incidents.

One of the most important functions of error handling is that it must allow the application to fail securely. Errors or exceptions must not compromise the application by exposing confidential information or allowing the user to do what is unauthorized for their profile. Just like a firewall should fail closed, an application should fail securely.

Errors and exceptions may mean that the information processed by the application has been processed incompletely. This may compromise the integrity of data or leave the application unavailable.

When writing secure code or reviewing the code of others, be sure to ask the following questions:

• Are exception handling mechanisms used consistently?
• Does the application fail securely? If so, how?
• Are open transactions processed appropriately if an error is encountered during processing?
• Are error messages displayed to the users informative without revealing information about system internals or other sensitive data?
• For function-based error handling, are return values of functions tested?
• For exception-based error handling, are specific exceptions caught, rather than broad exception handlers (i.e. Throwable in Java)?
• Are exceptions that are caught managed and logged (i.e. no empty catch{} blocks)?

Remember that software testing may not reveal how an application will handle errors, since it is often unplanned combinations of events and data that expose them. This makes finding them in source code review essential.

Read More...

Secure Coding Practices, Part 6: Logging

Logging is not always thought of as a security consideration, but it is important for on-going security monitoring. By logging events that help detect a security breach or attack, applications can provide early warning to security staff.

Although security monitoring may be out of scope for developing your application, the capability to log security events is important. Choose a commonly accepted logging framework to make your work easier and to simplify integration with monitoring software.

What should be logged? Typical audit events include authentication successes and failures, startup and shutdown of services, password changes, account lockouts, authorization decisions, job starts and completions, file transfers, and any other events that may be helpful in investigating security incidents.

Questions to ask when creating or reviewing application logging functionality:

• Are security-related events logged consistently?
• Is sensitive information, such as passwords, kept from logs?
• Are security events stored in a secure location and not mixed with common application logging?
• Are events logged in a format and location that is compatible with security monitoring/event correlation software?

Read More...

Secure Coding Practices, Part 5: Session Management

Session management security is especially important in web applications. A user can view and modify all information that is passed to and from a web browser. Popular browsers have plug-ins to make viewing and modification of HTTP traffic easy. As a result, the means of establishing, maintaining, and ending a session are in full view of the end user.

To make session management secure, it is important to encapsulate sensitive information in a way that the user does not see the data, but the server-side application can still identify the user and session properties.

Here are a few questions to consider when creating or reviewing web application software:

• Is session data excluded from the URL using the GET method?
• Does data in the browser cookie contain only the session ID and exclude other session information?
• Are session IDs hashed to prevent attackers from guessing valid session IDs?
• Are session IDs guaranteed to be unique?
• Are sessions validated on each page request?
• Do sessions expire after a period of inactivity?
• Are expired sessions deleted on the server?

Read More...

Secure Coding Practices, Part 4: Data Validation

Data validation is one of the most important secure coding practices, since it is the most exploited function of applications. Whether your organization creates web applications, desktop applications, or client server systems, data validation is crucial to protecting the applications, data, and servers on which they reside.

The most important data to validate is data that has come from user input or is received from another system or outside source. It is at this interface of information that information cannot be trusted until it is validated.

Validation of data is important to prevent:

• Injection attacks caused by characters that change the functioning of the program
• Buffer overflows caused by entering too much data in a fixed length buffer
• Cross-site scripting, which allows attackers to change the presentation of a web interface to redirect user input
• Data type validation, which may cause exceptions in programs that threaten system availability
• File corruption or tampering to validate the sender and contents of the file

Many data validation considerations can be found with automated static analysis tools, such as Fortify, Ounce Labs, Coverity, FindBugs, and Rough Auditing Tool for Security (RATS). These tools will alert you of many potential data validation issues. You will still need to review and validate the results, since these tools may produce false positives.

File corruption or tampering will need to be caught through manual review. Look for system-to-system file exchange points. Using asymmetric keys to provide non-repudiation of the sender, using encryption, or simply creating a hash of the file for validation will go a long way to prevent problems caused by tampering with the files.

Here are some review questions to add to your secure coding practices and your review checklist:

• Are all user inputs validated?
• Does validation check data length?
• Does validation filter or escape special characters?
• Does validation of web input remove tags before displaying it back to the user?
• Does the application validate the data type of user input before operating on it?
• Is XML received from outside of the application validated?
• Is the integrity of files sent and received by the application validated?

Read More...

Secure Coding Practices, Part 3: Authorization

Reviewing application authorization is an important consideration when reviewing code security. Authorization determines what users are allowed to do in the application after the they have successfully authenticated.

Proper authorization supports separation of duties. Information is better protected by giving users the least privilege needed to perform their jobs. Applications must support fine-grained roles in order to implement separation of duties when assigning users to roles.

When evaluating authorization in an application, here are a few questions to consider:

• Are permissions defined to create fine-grained user access?
• Are permissions defined for fine-grained administrator access?
• Are permissions enforced consistently in the application?
• Can permissions be grouped or organized to user roles for simplified access management?
• Are roles and permissions consistent with standards or other applications in the enterprise?

Make sure that your software developers understand the differences between authentication and authorization, as well as the importance of fine grained access to support separation of duties. Authorization controls are an important part of your secure coding guidelines and should be on your security code review checklist too.

Read More...

Secure Coding Practices, Part 2: Authentication

When considering secure coding practices and security code reviews, one of the most important things to look for is effective authentication. Authentication in applications controls user and system access. Without a complete authentication solution, there will be opportunities for an attacker to find ways to obtain unauthorized system privileges.

Here are some of the most important questions when evaluating authentication in applications:

• Does each web request validate authentication?
• Are credentials presented securely (i.e. using SSL, not using the GET method)?
• Are passwords stored in an encrypted or hashed format?
• Is password complexity enforced, including minimum length, non-guessable words, special characters, numbers?
• Do user credentials expire after a period of time?
• Are standards used for authentication and identity management (i.e. SAML, WS-Security, LDAP, NTLM, Kerberos)?
• Are user accounts locked after a certain number of failed authentication attempts?

If the answer to any of these questions is "no" then there is risk that authentication may be compromised. Risks in several of these areas may have been found in the requirements and design of the application. It is still important to verify that they have been implemented correctly when coded.

Discuss these questions with software engineers. Document them as part of your secure coding practices, and verify them when you perform a security code review.

Read More...

Secure Coding Practices, Part 1

When was the last time you did a security code review? If you are like most security professionals, this sounds foreign to you. For years, security has focused on the electronic perimeter, hardening of servers, patching third-party software, and access control. Today security is digging deeper into the nuts and bolts of the applications.

This is the first article in a series on secure coding practices. The goal is to introduce the software engineering side of security to help you develop a more comprehensive skill set.

One of the pillars of application security is secure coding practices. The security professional’s role in secure coding is first of all to help develop, communicate, and train software engineers in secure coding practices. To ensure that these practices are followed, security must be integrated into the software development process by performing on-going code reviews.

Code review is not the starting point for security involvement in software development. Before beginning code review, it is important to review requirements to ensure that security controls are defined. It’s also important to review system designs to ensure that there are no design flaws that can be spotted at a high level.

After security requirements are solid and the design looks good on paper, you are ready for code review. Code review for security is a combination of manual and automated processes. Your goal is to ensure that the security requirements and design artifacts are accomplished in the code and to uncover coding practices that expose application vulnerabilities.

Begin with developing secure coding practices and train the software engineers in your organization to use them. These practices should provide guidelines for at least the following security functions:

• Authentication
• Authorization
• Data validation
• Session management
• Logging
• Error handling
• Cryptography
• Performance
• Code Quality

You will also need a code review checklist that covers these areas, along with sections for describing the system context, end users, confidentiality of information, and availability requirements. You will use this form to communicate to developers on risks and to make follow-up notes when risks have been closed. The completed template also serves as evidence of due diligence, if you ever experience a security breach.

The articles that follow in this series will describe secure coding practices for each of the functions above to help you to develop secure coding practices, train your software engineering staff, and perform effective security code reviews.

Read More...

Welcome to Red Light Security

This is the first posting on Red Light Security. This blog is all about information security. Each post will provide techniques, trends, and tidbits on security. The focus at first will be on application security and security management, but it will expand to include all domains of security.

Please reply to the posts on this site. My posts will be based on my experience. You may agree, disagree, or have an opinion on the posts. Together, our views will help provide the best information for computer security professionals.

Technorati Profile

Read More...

Privacy Policy

Your privacy is important to us. Please review our privacy policy.

This privacy policy applies to all publications and web sites offered by Wyomissing Publishing.

If you have questions about this privacy policy, please write to: Wyomissing Publishing, 259 Church Road, Mohnton, PA 19540.

Information Collected During Your Visit

Most Wyomissing Publishing web sites offer free information that may be accessed without presenting information about yourself. Nevertheless, there is information that is collected during your visit:

• Cookies - Wyomissing Publishing sites generally use third party cookies to collect information for affiliate, advertising, and analytics programs. This information is not directly collected by Wyomissing Publishing.
• Log information - Log information is generally not collected. If web logs are maintained for any Wyomissing Publishing site, it is used to collect information about visitors, traffic patterns, and debug information.
• Information you provide - If you submit feedback on a Wyomissing Publishing web site, it may be retained to allow for follow up. Wyomissing Publishing also participates with third party web sites to allow subscription to email lists and related materials. This information is collected and maintained by the third parties and is not used directly by Wyomissing Publishing.

Choices for Submitting Your Information

You have the option to turn off cookies and refrain from submitting any personal information when visiting Wyomissing Publishing web sites. In rare instances, this may prevent you from accessing the web site or using it to its fullest value.

Sharing of Your Information

All information that is collected directly by Wyomissing Publishing is used only within Wyomissing Publishing and is not shared with any external parties. For submission of any information to participating third-party web sites, please refer to the privacy policies of these companies to find out about their information sharing policies.

Summary information that is collected about visits, visitors, pages, etc. and which provides no personally identifiable information may be shared with external parties from time to time in order to measure the effectiveness of Wyomissing Publishing.

Changes to the Privacy Policy

This privacy policy may change from time to time. Please check back periodically to see if there are updates.

Read More...