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?

No Comments
by on December 20, 2009  •  Permalink
Posted in Application Security
Posted by admin on December 20, 2009

http://redlightsecurity.com/2009/12/20/breach-of-the-drones/

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?

No Comments
by on December 16, 2009  •  Permalink
Posted in Application Security
Posted by admin on December 16, 2009

http://redlightsecurity.com/2009/12/16/implementing-trust-between-systems/

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?

No Comments
by on December 15, 2009  •  Permalink
Posted in Career
Posted by admin on December 15, 2009

http://redlightsecurity.com/2009/12/15/cybersecurity-in-2010-bubble-or-blip/

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?

No Comments
by on December 13, 2009  •  Permalink
Posted in Cryptography, Security Tools
Posted by admin on December 13, 2009

http://redlightsecurity.com/2009/12/13/on-the-fly-encryption-with-truecrypt/

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.

No Comments
by on April 28, 2008  •  Permalink
Posted in Virtualization
Posted by admin on April 28, 2008

http://redlightsecurity.com/2008/04/28/spinning-out-of-control-securely-managing-virtual-sprawl/

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.

No Comments
by on April 13, 2008  •  Permalink
Posted in Virtualization
Posted by admin on April 13, 2008

http://redlightsecurity.com/2008/04/13/patch-management-in-a-virtual-world/

Privacy on the Web: 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.

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 1×1 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.

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.

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.

No Comments
by on March 1, 2008  •  Permalink
Posted in Privacy
Posted by admin on March 1, 2008

http://redlightsecurity.com/2008/03/01/privacy-on-the-web-the-beacons-know-you/