Just before the sad event of Steve Jobs death, obtained a MacBook. While everyone is still immersed in reading the biography, we embarked on the journey of using a new OS for the first time. Here are the positive experiences and gripes that we found when using it in a multi-purpose multi-platform environment.

Please note that we are just starting up using the Mac, and some of our issues may have solutions that we haven't found yet.


The environment
The MacBook arrived in the very mixed environment of Shortinfosec

• Domain - an active AD Win2008 functional level domain, but used only for testing. The computers are only added to the domain to do research related to the domain.
  
• Computers - Work is done on our laptops - HPs, Lenovo and Acer running Windows 7, Vista and Ubuntu.
• Virtual environment - Virtual Box and VMWare player based virtual machines, mostly bridged network
  
• Network - 802.11 n Wifi and wired 1 Gbps Ethernet network. Cisco and Huawei network elements
  
• VPN - Cisco IPsec VPN for remote access
  
• Storage - iSCSI based storage server, built around an Openfiler storage server, on the wired LAN segment
  
• Printing - a very old HP LaseJet printer, so old that we have to use a Centronix to USB convertor, so we attach it to any laptop we need.
  

What we do on this environment:

• Testing and honing skills of attack tools
• Running test scenarios on corporate products
• Active Directory fiddling and trying to break
  
• Playing games
  
• Blog management
• A lot of article and paper writing
  
• Java development
• Odd accounting jobs
• Lots of games ;)

The positives
We like to start on a positive note, so here are the things we like about our Mac

• User experience - as Steve Jobs insisted, the user experience of working in Mac Applications on the Mac is seamless. Everything just runs. Even attaching external hardware a 20 year old printer was a breeze - much easier then doing the same on Vista.
  
• Battery life - the battery life is simply outstanding. The commercials say that the Mac can do 7 hours on battery, and that is quite true, for working in word processor, at 65% screen brightness.
• Portability - not really comparable, since all other laptops are 15'', but the Mac is very easy on the shoulders, and an excellent companion at meetings.
  
• Speed of functions - all implemented functions within the OS are implemented VERY WELL. For example, the Cisco IPSec VPN connection using the native Lion client authenticates at least 10 seconds faster than the Cisco VPN Client for 64bit Windows 7 (we actually measured)
  

The gripes
Naturally, not everything is that great, and here are the frustrations that we faced with our Mac.

• The keyboard shortcuts - putting an IT pro who worked on a PC and Unix for 20 years in front of a Mac running OSX is a special kind of hell: NONE of the keyboard shortcuts are the same, and it a significant effort to shift to OSX shortcuts. They are not illogical, only completely different, which hampers productivity for anyone used to do much of their work on a keyboard.
  
• Interoperability with other platforms - There are interoperability gripes with a lot of stuff. The Mac can join an AD domain (sort of), but we had a lot of stress getting the Mac to use cached credentials. Mostly the same happened with a Linux based LDAP service.
  
• Software is missing - A lot of productivity software that we are used to is missing for Mac - we stumbled on Visio, then on MS Project, then on Notepad++, then on 7zip... We didn't go into developing Java in Eclipse, because of the following point. Mind, there are replacements for most of the software we were missing, but productivity was hampered since we needed to find the appropriate software, buy it and learn how to use it. VMware player is nonexistent for Mac, we are limited to VirtualBox.
  
• Lacking native support for obvious items - first disaster - no support for NTFS write. We had to revert to the dreaded FAT32, which was a deal breaker for development. As if that wasn't enough, iSCSI is not natively supported, which further killed any attempt at accessing the large Java codebase on our iSCSI fileserver.
• Remote access - So far we haven't discovered an efficient native tool to access and work on our Mac remotely. The Apple Remote Desktop is a shameless highway robbery - why should any company or user need to pay any money to access and manage a single Mac remotely? We are at the moment trying out VNC, which is not a very preferred platform.
• No Native or Free Disk Encryption - (Updated, thanks to comments on reddit.com). Up to OSX 10.6 only Sophos SafeGuard provided full disk encryption for a Mac. For OSX 10.7 there is FileVault full disk encryption, but we haven't tried it.
  

Conclusions and thoughts
We are not abandoning the Mac - it is a great tool and an asset in our little lab. But in the current state of things, it takes a lot of effort and compromise to fully migrate to a Mac platform, especially since a multi-environment knowledge is required.

If today someone asks us whether a Mac is a good idea for company use, we would not be very supportive for the following reasons:

• Business Software lack of compatibility
• (Updated per the comment of Ryan Black) Incompatibility with writing to NTFS filsystem (which is everywhere) (previously stated NTFS fileservers - fileservers are accessed through SMB, which is supported)
  
• Learning Curve for efficient use

Talkback and comments are most welcome


Related posts
Information Risks when Branching Software Versions
8 Golden Rules of Change Management

IT has come a long way in the past 15 years, and definitely has advanced into the realm of commodity service. But there are still complexities under the hood of this commodity service. One of the most underestimated in complexity is data storage - it is taken for granted by everyone. For example, i frequently talk to a high ranking manager in a software company and he constantly states that all that is needed is another disk.



At the end of the day, data storage is very far from simple. Every organization needs to provide storage service for it's requirements. But storage is not only capacity, and one must be careful when choosing the appropriate solution for storage. There are three basic options at the moment:

• Cloud storage services
• Open Source based storage systems
• Commercial enterprise storage systems

We will evaluate each service from the following key parameters of a storage system

• Capacity - The first (and usually only) thing we think about when we talk about storage - and the easiest to achieve. Regardless of option for data storage, capacity is upgradeable. In open source storage systems which are based on commodity hardware, upgrades are limited to the abilities of the host server/box. The enterprise systems are much more upgradeable, but at high costs. For a cloud storage provider, capacity upgrade is nearly infinite (at least on paper). It is wise to plan ahead and consider whether future ability will support your requirements.
  
• Input/Output Operations per Second (IOPS) - The usually forgotten and very difficult to assess parameter, but nonetheless very important. The IOPS should present the amount of operations that the system can perform on a storage within a time-frame of 1 second. But since read and write operations on a storage can vary (sequential or random, read or write, even there are front-end and back-end IOPS when using RAID configurations). Cloud storage services do not publish IOPS, Enterprise manufacturers always publish the IOPS number that is most beneficial to them and the open source solution mostly leaves the IOPS to the builder of the system. In any case the end result is, DO NOT TRUST THE NUMBERS. There are some nice estimation calculators online, like wmarow's iops calculator, but use them only for reference. The smart solution is to test the storage service in a configuration as close to the one you wish to use, and assess whether performance is acceptable.
  
• Access Bandwidth - This is not disk bandwidth, which is calculated via the IOPS. The access bandwidth is the bandwidth between the server and the storage itself. Naturally, you want this to be as high as possible. For enterprise storage systems, discussing access bandwidth is moot, since such storage is mostly connecting through Fibre Channel which has multiple links of 2, 4 or 8 Gbps. For open source storage systems, which are mostly iSCSI based, the access bandwidth starts with 1 Gbps with Ethernet overhead. For cloud storage services, access bandwidth is a significant factor - cloud services are accessed through WAN links, where access bandwidth is limited and may be prone to congestion. When choosing a storage system, test your application with the bandwidth you are planning on using.
  
• Redundancy and high availability - What kinds of failures and incidents can a storage system survive? Cloud services claim that they can survive a lot - short of a cataclysmic event or a nuclear bombing - but such claims should be tested. Enterprise storage systems are designed to survive nearly any hardware issue within them, and provide abilities to replicate to other systems which are at a distance of tens of kilometer (naturally, at a high high price). Open source storage systems redundancy is dependent on actual hardware redundancy of the box the customer built, and provide some technologies for replication, which are in a different level of maturity. Always consider placing the data based on the importance to the company - can you survive without it?
  
• Actual hardware - storage systems are comprised of well known components - hard drives, controllers, interfaces, power supplies. For both enterprise storage systems and for cloud service the customer does not need to bother too much with the hardware - the provider constructs and combines the required hardware. On the other hand, when preparing an open source storage, the customer usually builds the hardware which means finding appropriate hard drives, RAID controllers, redundancy in power supplies, caching mechanisms, LAN and FC interfaces. Building a system from scratch is a great experience, but commodity devices may be prone to much more failures then specially built hardware. Testing is not very useful here, but think ahead of the very possible risk of failure of commodity components.
  
• Reporting - Once the storage system starts working, reporting becomes an immediate issue. The customer will want to know the load on the system, on individual hard drives and logical devices, response times, utilization trends etc. Again, enterprise storage systems shine in this area with an excellent portfolio of reporting tools, albeit usually with exorbitant prices. Cloud storage services may provide some reporting but not too in-depth, and the open source systems usually lack poorly, since the open source project is focused on functionality, not reporting. When choosing any storage system, always ask to look at the live reports from the service/system you are planning on using.
  
• Support - Again, once the storage system starts working, there will be problems. And I guarantee you - the problems will not be simple: either it works or it doesn't. There will be all kinds of complicated and seemingly impossible combinations of issues. And this is exactly where the customer will need support. But there is no clear-cut answer to which type of storage system has the best support. One must tread carefully here, because good support is about having trained support personnel, but also having very dedicated support personnel. By definition, enterprise storage systems have a great advantage in this area, but this advantage can easily be ruined by a support team that juggles many projects, is used as presales or is simply not dedicated to supporting a customer. Cloud services fall in much the same category, but it can be difficult to discuss storage issues with a cloud storage service: the engineers are impossible to reach, there is insufficient data to support an issue (reports, analysis) and the cloud service provider has usually a well crafted SLA to protect themselves from most issues. The open source systems are an issue of support in a different way - since the systems are built with software which is written by many, there are rarely any real experts to support such a system, unless you pay someone - and even then it may be a risk.
• Vendor lock-in - Cloud storage services are the strongest player in this area - if the customer chooses a cloud storage system as an important part of your infrastructure, it will adjust it's operation to the cloud system and create a 'symbiotic' bond, thus making the migration very costly. Enterprise systems are much easier to migrate from, since they are basically just huge hard drives. If all else fails, an operating system level copy command will provide a very crude but always successful migration. Open source storage systems have no lock-in: simple hard drives, where migration is a copy-paste operation.
  

Conclusions
There are multiple pros and cons across our storage systems parameters, but at first glance, the enterprise storage systems have the upper hand. Bear in mind though, such systems always come with exorbitant pricing, especially on any upgrades after the initial purchase. Therefore, such systems may be well suited for the mission critical applications, but are too price prohibitive to be used for every and any use within a company.
The cloud services are extremely flexible in expansion capacity and redundancy (at least on paper). But quality of service and support may be lacking, as well as issues in speed of access. So cloud based storage may be only logical if you rent the full package - server plus storage in the cloud, to guarantee an overall service level. The remaining issue is lock-in: once you start using a cloud provider, leaving it may be a challenge, since you have adjusted your operation to it's service and it may be costly to shift providers.
The open source systems are an interesting project, and can provide a very cheap solution for a lower tier functions. But in order to actively use such a system would mean to dedicate an employee or a team of homegrown experts on the open source storage system, to properly support the system. Also, redundancy and high availability can become an issue in such systems.

In summary, do not choose only one storage solution: The enterprise system is well suited for the business support, but it is a huge overkill for a test or proof of concept systems. Cloud storage services are a good choice for a cloud based infrastructure, but the lock-in issue requires careful strategic approach before lock-in occurs. So use everything, and always evaluate any solution for at least 3 months before committing to it.


Talkback and comments are most welcome


Related posts
RAID and Disk Size - Search for Performance

Centralizing your storage is always a very good idea - you can manage storage requirements of most servers through a central storage system, without the hassle of juggling local disks within servers.

But centralizing a storage opens a whole new world of hassles:

• Physical limits- depending your choice of vendor and class of storage you may be limited by number available slots for drives
• Technical limits- depending your choice of vendor and class of storage, it may support hundreds od drives, but not with your current CPU's or cache memory
  
• Higher costs - everything within the storage costs - physical drives, CPU's, cache memory, drive bays, licenses for storage management software. And all these usually have exorbitant prices.

So when looking for a storage, there is always a tug of war: limited budget vs functionality, drive space and performance.

Let's discuss all three elements countering the budget:

• Functionality - this are covers overall management, non-disruptive OS upgrades, point-in-time snapshots, point-in-time clones, replication functionality etc. These are very easy to declare as requirement by the client, and leave very little 'wiggle space' for the storage vendors to try to sell something else or reduce the price at the RFP by reducing .
  
• Drive Space and Performance - Here is the conflict between storage vendors and clients: Storage vendors do not sell space and rarely sell performance, they sell hard drives. And everything in their portfolio (cache, slots, licenses) is based on physical drives. So they will always push the client into a 'number of drives' mentality. This is wrong, the client needs to think in terms of useable space and Input/Output Operations per Second (IOPS), because at the end of the day, the servers do not care that you have 20 drives, when they see only 100GB of partition and only 200 IOPS when they need 1000. And here we hit the problem of balance - as you are well aware, a storage can provide different levels of data protection through redundancy or parity, at the cost of physical capacity and performance.

When declaring your useable space, you need to either declare the number of IOPS that it needs to support or (which is very difficult) or to declare a RAID level. Since estimating actual IOPS requirement is difficult, you can always approach it with a 'I need a better functionality then I have at the moment'. This is very easy to achieve with the Wmarow's IOPS calculator:

1. Input the parameters for number of drives and raid level that is currently servicing your server.
2. Then input the estimated number of drives and organization (RAID) that you are thinking of buying.
3. Compare the IOPS results.
4. If you are migrating more servers to one RAID group, add up all initial IOPS and compare to the one resulting IOPS
   
5. You need to achieve a better IOPS result for the target then currently, by at least 50%
   

The results will vary wildly, based on number and type of drives, as well as RAID level. We have calculated a sample of IOPS results for a 2 TB capacity drive using different RAID levels and disk drives, with an assumption of using a small storage with only 16 slots for disks (click the image for large version):



Please note that the actual IOPS result of a certain storage system may be different in absolute value, because of processor power, advanced algorithms and cache memory. But regardless of these attributes, the relative ratio between the produced IOPS will remain the same - RAID0 will be always 3 times faster then RAID5 on same drives.

Also, please note that no matter what the abilities of the storage system that you are looking at, there are physical limitations to each disk, and these cannot be overcome by any amount of cache, intelligent algorithms or processing power of the storage system.

In conclusion, since the absolute value of different storage system may be different, what is the best way for a client to be certain that he/she will receive the balance of protection and performance that is needed ? There are two options:

1. Test the configuration. If someone wants to sell a storage, he/she should be able to create a same configuration storage at a lab environment, and you then generate a full load of performance and load testing of the configuration
2. Ask for a guarantee - give the salespeople the parameters of the services on the servers (databse, file servers etc.). These can be collected through performance monitor and database tools. Then make the vendor guarantee with financial penalties that any of the functions will perform two times faster (or any other parameter) with the same servers.

Talkback and comments are most welcome

Related posts
Choosing a System Integrator - Follow the money
Cloud Computing - Premature murder of the datacenter

In 2008 we published an article on cloud computing, which basically said, don't turn off your local datacenter. To be very sincere, Shortinfosec was a little hypocritical in that article - since Shortinfosec was and is hosted in the cloud. After three years, and a lot of additional examples of cloud development, it is time for a serious reconsideration:

Our original argument was that the confidentiality, availability and integrity triad was unsustainable in the cloud world at the time (2008). Today, things are looking different:

• Backup storage is humming in the cloud in some form or another - and is being used by enterprises
• At least 3 different vendors of banking software are collaborating with cloud services providers to enable the cloud operation of their software (Tieto, Misys, Temenos)
• E-mail and office applications are happily running in the cloud (Google, Microsoft)
• Web applications are more available then ever
  

Since this article will become too long if we discuss all possible cloud applications, let's start with the simplest one - Web hosting.

From it's inception, web hosting was in a sense hosted in the cloud - but a very simple cloud. Very few people or even companies own and operate web servers, and others host their web sites on provider servers throughout the world.
But hosting is not exactly the cloud. The cloud offers so much more for web hosting.

Now, this is not the time to start thinking: "I'm thinking of upgrading my web host and I've been checking some web hosting reviews. It's pretty hard to decide which host especially when reading the editorial and user reviews since all of them have good reviews." Let's go on and choose the most expensive one."

When reviewing moving the web to cloud, understand the strengths and weaknesses of the cloud:

Strengths

• Availablity - any cloud service is distributed over multiple servers, datacenters and sites. And the cloud systems can transfer the hosted applications/sites near-instantly between this infrastructure. So even if a server fails, your availability will be nearly unharmed.
  
• Coping with large load variations - again, since there are multiple servers and datacenters, if your application/site suddenly become very popular, the cloud infrastructure won't fall to it's knees under the load of additional requests.
  
• Timely and consistent updates - the underlying servers of the cloud infrastructure need to be fully consistent with each other. Also, since they are running many customers applications/sites, a failure due to a patch is not something the cloud service will accept. So you can rely on the fact that all servers will be very quickly and consistently updated.
  
• Extremely fast scaling out - If your application/site has a sustained high visit rate, it needs more servers to run on. This is very easy to implement in a multi-server, multi-site environment of a cloud service.
  

Weaknesses

• Custom platform - each cloud service provider designs the cloud service environment with it's specifics, like underlying operating system, databases, application server and development platform. These are fixed across the entire cloud platform, and if you wish your application/site to run on the cloud service, you must make it work with the cloud service.
  
• Lock in - once you have adjusted the entire application/site to run on the cloud service environment, it may be difficult to move it to another cloud service provider - since then you'll need to re-adjust everything to run on the new cloud service. This is even more difficult if the application/site was developed from scratch with specific cloud service in mind.
  
• Isolation breach - your application/service is not the only one running on the cloud service systems. A breach between the isolation controls of different applications/customers can cause access to proprietary data, use of other party's resources and in general a very large amount of grief for everyone involved. At the least, you could be billed for resources that another application in your context due to such breach
  
• Data protection - placing your application/site in the cloud also puts it's data in the cloud. And this data is very important to you, and sometimes very confidential in nature. Since all this data is managed by the service provider, incidents of data loss, data leaks and security breaches can all happen.
• Cost - the cloud service providers have a lot of innovative pricing mechanisms, like pricing per I/O, or per CPU used, or bandwidth, or any combination of those. So while efficiency and availability will definetly increase, so may the costs of your hosting.
  

The cloud is very ripe for web services. But before you choose one, be careful to do a serious consideration on your pros and cons. If you can match your application/site to a cloud service, you can bring it to a new level of efficient operation.

Talkback and comments are most welcome

Related posts

Cloud Computing - Premature murder of the datacenter
Web Site that is not Easy to hack - Part 2 HOWTO - the web site attacks
Checking web site security - the quick approach
Tutorial - Secure Web Based Job Application
Rules for good Corporate Web Presence

Having an anti-virus on your computer systems is one of the standard best practices for every computer user, regardless of whether you are home user or a business.

Although there are a lot of users (both corporate and home users) that consider the anti-virus a useless weapon, it still provides a very real protective layer on your computers. No anti-virus is 100% effective, but even at 80% effectiveness, it means a whole lot less problems with malware.


Here are some simple guidelines for selecting and managing your anti-virus environments:

Home Environment

Managing an anti-virus in a home environment is relatively easy. Most users have 2-4 computers in the home, and they need to set-up an anti-virus on everyone of them. The most important elements are

• Regular updating of signatures from the manufacturer
• Active real-time protection
  
• Regular (weekly or monthly) scheduled scan

In order to keep your home anti-virus system in good condition, you need to

• Set the antivirus to perform automatic cleaning with quarantine (no delete) - this way even if you get a false positive, the file isn't deleted and you can rescue it from
• Check the update version - check whether updates are still current and there are no issues with updating
  
• Review the last scan results - this way you will be alerted if malware is identified
  
• Review the quarantine - to find if false positive files were captured by the anti-virus and need to be 'rescued'
  

Choosing the product
Then it's about the price and functionality. The home user can choose a free product, or they can buy antivirus protection. Here is a sample of criteria to review when choosing the anti-virus:

• Legitimate antivirus software - What you need to be very careful about when implementing a home antivirus environment is that the product be really an anti-virus. Wikipedia references the SpyWare Warrior that more and more malware masquerades as legitimate anti-virus. In order to avoid these malware decoys, you can reference the Wikipedia list of anti-virus software .
• Range of malware that you are protected from - Can the engine detect virus, spyware, rootkits, etc.?
  
• Behavior-blocking - Does the antivirus monitor system calls with a heuristics engine to prevent vulnerability exploitation attempts and zero day virus breakouts?

Corporate Environment

Managing an anti-virus in corporate environment is a lot more work. There are hundreds, even thousands of computers that need to be protected. In such an environment you need to battle the following battles:

• Keeping clients up-to-date - when updating hundreds of computers, there will be issues - computers that are off, computers where the antivirus software has failed for any reason, issues in communication with the update server
  
• Keeping clients compliant to policy - same as above, updates to policy may fail or be in significant delay
  
• Preventing the anti-virus servers from overloading - updating hundreds of systems can cause hogging of the update server or the Internet link.

In order to keep your corporate anti-virus system in good condition you need to

• Set up updating frequency according to corporate policy - updating the anti-virus in a corporate environment needs to be planned - updates may be needed more then once per day, but if you make the updates too frequent you'll end up overloading the antivirus server with requests.
• Balancing the load of management and updates in a distributed environment - When you have branches, it is wise do distribute the burden of updates and management to branch servers and administrators.
  
• Implement additional policy elements- anti-virus software may also be used to enforce corporate policies of not running some software in certain parts of the day (example - block media player from 9 to 12 and from 2 to 5)
  
• Schedule automated scans - similar to the home users, scheduled scans are good for confirming that nothing is sleeping in downloaded documents, unopened files etc.
  
• Schedule automatic reports - Your best for keeping the corporate antivirus infrastructure in good condition is an automated report. This way, a report on the number of non-updated

Choosing the product
When implementing a corporate anti-virus solution, the criteria of choosing a legitimate (non-malware) antivirus is not important - there are no malware products designed to operate as a corporate antivirus systems.
And even if someone tries to make such a malware, it will be immediately identified, since corporate anti-virus solutions are constantly evaluated - both by independent technology sites and companies, and by other manufacturers of anti-virus solution - to assess the competition.

But there are other criteria for corporate anti-virus that need to be evaluated. Here is a sample of criteria:

• Range of malware that you are protected from - Can the engine detect virus, spyware, rootkits, etc.?
  
• Behavior-blocking - Does the antivirus monitor system calls with a heuristics engine to prevent vulnerability exploitation attempts and zero day virus breakouts?
• Expanded functionality - System firewall. Does it provide blacklists and white lists for addresses and domains?
• Policy control - Does the antivirus provide controls to enforce corporate policies regarding use of certain elements of the computer system? For example, an antivirus system may provide policies to prevent running of certain applications, although they are not malware, or prevent access to usb storage devices etc...
• Signature Updates - How large and frequent are signature and other updates? This can range from one per day to multiple updates per day. This is a very significant issue - a signature that is updated once per day, it can be quite large, so in a large corporation the update process will hog the central antivirus server.

Conclusion
Depending on whether you are running a home or corporate environment, you face different challenges with antivirus solutions. But regardless of environment and product, you will be very grateful that you are running an antivirus the day someone you know looses data or re installs their computer due to a virus corruption.


Talkback and comments are most welcome

Having an accurate depiction of your network is a fundamental prerequisite to being able to successfully handle system management, troubleshooting and growth. With the advent of network mapping tools, this process has become more simplified.

At the dawn of computer networking, interconnected systems were often contained to a building, if not a single room. But today's corporate networks span cities, countries, and the globe. This complexity has made network management an increasingly difficult task.


There are three techniques that are used to gather network information:

• SNMP – data is retrieved from routers and switches
• Active – probes an IP address range using trace route type functionality
• Route – analyze routing protocols

Measurable improvements have been noted in the time it takes to perform network management tasks. You can easily track inventory, monitor host uptime and downtime, services, applications and a myriad of other options. In addition, administrators can better understand the relationship between devices and the transport layers that connect them. This aids in faster identification of potential network issues.

Network maps are also an excellent security tool, as they are able to provide a snapshot of who is connected to wired or wireless networks at any given moment. If a map reveals a suspicious connection or IP address, it can be monitored or disconnected. Mapping views are customizable, providing as much or as little information as you need.

It should be noted that network mapping is most effective when it isn't viewed as a onetime task. The dynamic nature of networks, demand this to be an ongoing, periodic activity. As systems change, software or operating systems updated, a new map will need to be created to reflect the changes. Some organizations employ a weekly schedule, others, more often. While frequency will largely depend on the size and complexity of your network, developing a consistent schedule is what's most important.

This guest post was provided by Veronica Henry on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. More information about GFI network auditing software can be found at http://www.gfi.com/lannetscan/network-auditing-software.htm


Talkback and comments are most welcome


Related posts
DHCP Security - The most overlooked service on the network
Example - Bypassing WiFi MAC Address Restriction
Obtaining a valid MAC address to bypass WiFi MAC Restriction

When preparing a Disaster Recovery Center, one of the most important decisions is the location of the location of the Disaster Recovery Center. Up until the 9/11, a lot of companies held their DR centers in the adjacent building, and right after 9/11, everyone wanted to go as far from the primary data center as possible.


One of the common misconceptions of Disaster Recovery planning is that longer distance ensures better disaster protection. Of course, increasing the distance between data centers reduces the likelihood that the two centers are affected by the same disaster. But just putting distance between locations may not be sufficient protection. In reality, the best distance for a DR location is dictated by a multitude of factors:

• Minimal parameters dictated by regulators - certain businesses, especially telco and finance must maintain regulatory compliance. It is not unusual for regulators to mandate minimal distance between the primary and the Disaster Recovery location. You must comply to these parameters
• Corporate RTO parameters - the company has decided that the Disaster Recovery Center must be up and running within the time defined as RTO - Recovery Time Objective. This time will include the travel time to Disaster Recovery center and the system activation times. So it is always important to take this parameter into account when choosing a Disaster Recovery site
• Telecommunications services - larger distance between the primary and DR site means higher telecommunication costs and limits the choice of appropriate remote copy technology. For instance, synchronous replication is still very difficult to achieve past the 40km mark. Choose a location that is sufficiently distant but still manages to deliver the required bandwidth for the chosen replication/remote copy technology
• Geophysical conditions -In order to avoid a natural disaster, it is not always sufficient to move your Disaster Recovery center to a specific distance from the primary center. Most natural disasters deliver high impact in areas which support their spread by terrain configuration or other geophysical conditions. For instance, a safe hurricane impact distance was considered 150 km. However hurricane Katrina lost strength after over 240 km inland since there was no terrain feature to stop it. Best location should be in a separate flood basin, off a seismic fault line (or at least on a different one) and with a large mountain between the primary and the DR site
• Means of Transportation - increased distance between primary and DR site may make it difficult for employees to travel to the recovery site. This is especially true in situations of crisis, when roads may be damaged or blocked, or public transport is stopped by strikes. Choose a site that has multiple travel options - railroad, motorway, even river boat
  
• Vicinity of Strategic objects - It is never smart to place your Disaster Recovery center in the vicinity of objects of strategic importance to the country. Such locations are prone to terrorist attacks, and attack by opposing forces in a military conflict. Also, even in situations of natural disasters, strategic locations will have strong military presence that may limit access to your Disaster Recovery center. Strategic objects are military bases, airports, refineries and oil depots etc. Choose a safe distance from such locations
  

There is no such thing as an ideal Disaster Recovery location. The optimal location is the one that minimizes the risks at an acceptable cost and meets the required SLAs and authorities' regulations.

Talkback and comments are most welcome

Related posts
Mitigating Risks of the IT Disaster Recovery Test
iPhone Failed - Disaster Recovery Practical Insight
Business Continuity Analysis - Communication During Power Failure
Business Continuity Plan for Brick & Mortar Businesses
Example Business Continuity Plan For Online Business

The IT Disaster Recovery Test as part of the Business Continuity testing is becoming an annual event for most IT departments. It is mandated by a lot of regulators, nearly insisted upon by internal audit and ofcourse a very healthy thing to do.

But performing the IT DRP test without proper risk management can put your organization at significant risk.


To put things into perspective, let's analyze the steps, risks and countermeasures of an IT Disaster Recovery test:

DRP Test Step	Activity	Risks	Countermeasures
1. Failure of primary systems	In order to perform a disaster situation, the Primary systems need to be caused to fail on some level	Databases not closed properly/damaged due to forced shutdown or forced power failure Hardware components failing due to forced shutdown or power failure Spilt-brain cluster due to uncontrolled sequence of failures of servers and storage	Full backup prior to the initiation of the DRP test Backup components and Vendor presence at ready during the entire test. Not performing a direct forced shutdown but forcing a network level isolation at the routers
2. Activation of Disaster Recovery systems	Severing any relation between the DR and the primary systems and running the DR systems as temporary primary	Actual failure of primary system during the test Failure of the primary system while the DR system is concluded to be non-functional	Full awareness of the test of every interested party - business custodians, directors of divisions and top management to initiate the real Business Continuity Plan Full backup prior to the initiation of the DRP test at DRP site, and full vendor support.
3. Reconfiguring the user environment	Intervening in the end-user environment in a way that will make them use the DR system	Error in reconfiguration which may cause the end-user to input test data into the primary systems Error in reconfiguration which may cause the primary system to stop functioning.	, 2. Scripted and documented steps of reconfiguration. All steps should be performed by 2 persons - one observing the others actions
4. Reverting to the primary systems	Resuming the primary systems at some level and reestablishing the relation between the DR and the primary systems	Error in reconfiguration which may cause the primary system to stop functioning. Copying of test data that was input into the DR test system back into the primary location3. Failure of primary systems during resumption	Scripted and documented steps of reconfiguration. All steps should be performed by 2 persons - one observing the others actions. Fully controlled and documented process of resumption, which guarantees that only the primary system is data master. Full backup prior to the initiation of the DRP test, Backup components and Vendor presence at ready during the entire test.

With all these risks, is it more prudent to never perform an IT DRP test? - Absolutely NOT, and here is why:

• Performing the IT DRP test actually confirms that things are running, and if something breaks, you are much more prepared for the next time.
  
• Not performing the test will just make you think everything is great, until the incident occurs. And the incident is just as certain as death and taxes
  

So, perform the IT DRP test regularly, but with a whole set of countermeasures for the possible risks which can happen during the test. Of course you will miss some risks, but if you plan for 10 and miss 1 is much better then not planning at all!

Talkback and comments are most welcome

Related posts
iPhone Failed - Disaster Recovery Practical Insight
Business Continuity Analysis - Communication During Power Failure
Business Continuity Plan for Brick & Mortar Businesses
Example Business Continuity Plan For Online Business

After all the risk assessments, cost analysis and decisions, you decide to send your data into the cloud. And things are good - at least until the security breach.

When that happens, every security professional and IT management will get grilled by top management. Youtube has a mockup video that just might give you the feeling of how this will look like.

Ofcourse, a video of Hitler reacting to a hacked cloud computing service is a bit of an overkill. But be sure that you'll hear a lot of the sentences that are mocked up, even if not in that tone.

You can see the video here


Talkback and comments are most welcome

Related posts
Security Concerns Cloud “Cloud Computing”< How to Trust Cloud Computing
Cloud Computing - Premature murder of the datacenter

Security and privacy in cloud computing are hot topics, and everyone has a take on it. Cloud computing providers deliver their levels of security and privacy by their internal policies and procedures, but the rigidity of these policies are strongly influenced by government regulations.

If the country within which a cloud computing provider resides or is registered has lax provisions on privacy, do not expect wonders in the protection of your hosted data - especially since such lax provisions may even be created to allow government agencies to gain access to hosted data.

Forrester research felt the pulse of things by investigating the regulatory frameworks of countries throughout the world. Here is a brief of the results of this research

Country-specific regulations governing privacy and data protection vary greatly. To help you grasp this issue at a high level, Forrester created a privacy heat map that denotes the degree of legal strictness across a range of nations.

You can investigate the map here. To be very sincere, i would like my data to be either in Germany or Argentina. Oh, and USA just got a proverbial slap on the face by being classified in the same category with Colombia, Paraguay and Russian Federation.

The esteemed senators and congressmen in the USA should think hard about moving up the ladder of privacy and data protection if they don't want to be soon classified in the same category as China :)


Talkback and comments are most welcome


Related posts
Security Concerns Cloud “Cloud Computing”
How to Trust Cloud Computing
Cloud Computing - Premature murder of the datacenter

Communication links provided by Telco providers are critical to most businesses. And as any network admin will tell you, these links tend to have outages, ranging from small interruptions up to massive breakdowns that can last for days.

When such interruptions occur, businesses suffer, but unless the provider has serious contractual obligations, there is little effort on their side to improve service or correct issues.

That is why businesses need a good Service Level Agreement (SLA). Usually, the preparation of the SLA is dreaded by most, since it is full of numbers and parameters on which the client must decide what is acceptable, and whose values may be difficult to measure.

SLA Parameters
A good SLA is not necessarily loaded with a lot of numbers. You need to work with 2-3 parameters which are important to you. Here are the most frequent SLA parameters, with their acceptable values:

• Availability - more then 99% for internet, more then 99.5% for corporate data links
  
• Packet Loss - less then 0.4% for internet, less then 0.2% for corporate data links
• Jitter - less then 15ms for internet, less then 5ms for corporate data links

SLA Penalties
And you need penalties which will hurt the provider. Penalties are the big stick in the SLA.
Here are the penalties that you want:

• small breach of SLA - 25% to 33% of monthly fee
• large breach of SLA - 50% to 100% of monthly fee

Be aware that no provider will create an SLA that will eat much of it's profits. The commited provider can be identified by the type of Service Level Agreement (SLA) that it's prepared to sign without special negotiations.

Here are three different levels of SLA's - not so much by the metrics and parameters, but quite different in terms of penalties

• Verizon is offering a very basic SLA, with compensation of the daily charge for each day of SLA breach - http://www.verizonbusiness.com/terms/latam/co/sla/
• BT is accepting a more serious approach - a penaltyof a daily charge for each hour of SLA breach, but with a limit of maximum 10 days of charge in penalty http://business.bt.com/assets/pdf/BTnet%20Service%20Level%20Agreement.pdf
• Sprint is including some really hard penalties in their SLA, including a 100% of monthly charge in penalties for some parameters. http://www.sprint.com/business/resources/mpls_vpn.pdf

Talkback and comments are most welcome


Related posts

9 Things to watch out for in an SLA
The SLA Lesson: software bug blues
5 SLA Nonsense Examples - Always Read the Fine Print

Large enterprises rely on software products. And as everything else in large enterprises, the software products are large, complex, cumbersome and nearly unchangeable. This last attribute is better known as vendor lock-in. Software vendors love vendor lock-in. Here is a definition borrowed from Wikipedia:

Vendor lock-in, also known as proprietary lock-in, or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs

The problem
Vendor lock-in exists in most large enterprise industries like Telco, Healthcare, Finance, Energy. Such industries rely heavily on certain computer systems or software products, usually dubbed Core Systems. Because most of the business transactions, logic and information are stored and processed by these Core Systems, the transition to a different Core System vendor is extremely costly and time consuming.

So most large enterprise companies simply continue to operate with the same Core System vendor, while they suffer:

1. delays in patch or version delivery
   
2. poor quality product versions
3. inadequate compliance from the Core System to their local law and regulation
4. ever increasing maintenance costs.

On the other hand, switching to another Core System vendor will result in probably the same end effect, with the added costs of the switchover.

The solution
So is there a way to improve your position? Indeed there is, but with a radical move: there is only one thing that any software vendor reacts to - risk of decrease in earnings from a customer.
To make this risk a reality for the vendor, the customer needs to reach a situation where competitors can successfully bid for software upgrades and new functionality without actually switching the Core System.

This is most easily achieved through the Core System's API interface. Most Core Systems have extensive Application Programming Interfaces (API), which can be used to exchange data with the Core System or issue commands to it.


So instead of asking for every possible modification or new functionality from the Core System vendor, just use it as a processing core - move everything else to other developers, which will need to adhere to the Core System API specification.

This way you can outsource the development of a lot of applications to other vendors, achieve better response from everyone and always have healthy competition. Oh, and it will keep the Core System vendor on it's toes!


Talkback and comments are most welcome

Related posts
Software vendor relationship - can you make it better?
3 rules to keep attention to detail in Software Development
Security challenges in software development
Paying for Software Support - When to do it?

Cloud Computing is becoming more and more the buzzword of every conference, meeting and article. Yet it is still in it's inception, and there are multitude of issues and problems. Cloud services are springing up like mushrooms after rain, and all the big players want a piece of the pie.

Dark Reading discusses Quelling 7 Cloud Computing Fears in which it touches the issue of trust and security. The author recommends that the cloud computing providers be proactive in gaining the trust of their users and potential users.



How do we decide when we trust the cloud?
Here are the mechanisms by which we can approach the level of trust that we have in our infrastructure for the cloud. But bear in mind, that each approach can have it's own pitfall!

1. Encryption - Most readers will immediately start to think about encryption. Yes, it is a good idea, but is it enough? In encryption, regardless of the algorithm used, you are always dependent on the actual implementation of the algorithm. If the implementation is flawed, there can be back doors into your data. And you can't control or check the implementation - it's in the cloud
2. Certification to Security Standards - A logical industry choice - if you are certified to a security standard, you are all good and well. But tread very lightly and be very careful about this: most security standards are quite flexible - you can choose to certify only a subset of your operations. So a security certificate of the data transfer subsystem won't do you much good when you are using the cloud for storing your customer database - the data storage and processing subsystem may not even be up to the security level of your home PC!
   
3. Compensating Penalties (Contractual and via Litigation) - You can try to define penalties for breach of security within the service contract. But the cloud provider will limit such penalties to a limit which may be far below what you estimate to be your financial impact, and simply refuse to offer the service if you insist on full penalties. And unless you have an army of international lawyers on your payroll, don't even try to go into litigation - you'll end up loosing even more money in the trial.
   
4. Insurance - Transferring the financial impact of the failure can be an elegant solution. But the insurance company will start asking the same questions about trusting the cloud provider and can quite easily deliver a significant premium charge on your insurance.
   

Conclusion
There is no magic wand that will make the users suddenly increase their trust in the cloud computing services. But agreeing on a common standard for what is required to be met in terms of Confidentiality and Integrity is a step in the right direction.

We recommend that the minimal requirement should be:

• Always insist on the cloud provider having a valid Security Standard Certificate which covers the entire scope of services that you plan on using.
  
• Contractual penalties should be in place for everything that can be quantified. This means that you'll even need to quantify loss of every byte of data.
  
• If possible based on the cloud computing service that you use, encryption should be implemented for the data stored/processed in the cloud.
  

Talkback and comments are most welcome

Related posts
Cloud Computing - Premature murder of the datacenter
Datacenter Physical Security Blueprint

As an Information Security professional I think it is increasingly important to understand the difference between IT Risk and Information Risks. You should also understand the advantages in enabling business strategies by ensuring that you brand each one of these risks accordingly.

Here are my high level definitions:

• IT Risks - The probability that a vulnerability of an information technology solution or asset will be exploited and the likely damage from the exploitation.
• Information Risks - The probability that information/data can be exploited and the likely damage from the exploitation.

While these may seem similar to the layman, they should clearly be viewed and positioned differently by the Information Security professional. Here's why:

• IT Risks should have a focus on technology, while
• Information Risks should not have a focus on technology

By clearly positioning the two as different, it is easier to delineate responsibilities when partnering with the business on managing risks. Knowing who owns what always increases your chances of being successful. IT risks given their technology orientation, will rightfully so land more on the plate of IT professionals plate to manage vs. the business. Information Risks should accordingly land more so on the business side. When I say "land" from a responsibility standpoint, I mean from a custodianship standpoint, not who is ultimately (final review /approval) accountable. The business is always ultimately accountable for managing risks.

By leveraging these two definitions, not only are you able to better delineate responsibility, it ensures that vulnerabilities in non-technology related areas are more effectively addressed through the lens of "Information Risk". For example, if one solely focuses on IT Risks related to privacy breach you can too often over look the many vulnerabilities related to privacy risk on things like supervisors approving inappropriate access to personal information or poor physical security to offices containing personal information.

You may encounter different terminology for the above two risks. Don't get hung up in terminology. You can call these two things anything you want. Some call IT Risks -(Technology Risks), some call Information Risks - (Data Risks), some even call Information Risks - (IT Risks). Just know that one of these deals with the risk associated with technology being exploited, which of course can have an impact on information, but also on a lot of other things. The other is focused solely on the information and data, and should not be solely tied to technology factors.

This is a guest post by Mark Brooks, a consultant and leader in the field of global information risk, security, and compliance.

The original text is published on IT Security Blog. Mitigating Risks. Enabling Business Strategies

Related Posts

Role of Information Security Manager
Template - Corporate Information Security Policy
Risk Assessment with Microsoft Threat Assessment & Modeling
Example Risk Assessment of Exchange 2007 with MS TAM

For the fifth issue of the Information Security and Strategy Carnival, I am pleased to present the following texts:

• Dan Cornell over at Denim Group posts a great article on 13 Things a Web Application Attacker Won't Tell You as well as 5 More Things a Web Application Attacker Won't Tell You

• John P Mello at AllSpammedUp has a take on benefits of spamming social networks in Why social networking spam reaps more rewards than email

• Roger Halbheer from Microsoft discusses Why it pays to be secure – Chapter 4 – I want to learn!

Please send submissions by the 25th each month to e-mail:shortinfosec _at_ gmail dot com

Related posts
Information Security and Strategy Carnival - Issue #1
Information Security and Strategy Carnival - Issue #2
Information Security and Strategy Carnival - Issue #3
Information Security and Strategy Carnival - Issue #4

Evaluating Security Information Event Management (SIEM) solutions come in a lot of different flavours. The industry is not yet mature, and the competitors are pushing their own solutions, based on their background and capabilities. In general, they will all present more or less the following configuration model for the SIEM implementation.


But other then the generic model, a lot of things are different. So, in order to sift through the multitude of solutions, the buyer needs to ask the real questions. Here are some of the key questions that need to be taken into consideration:

• Is it possible to place an agent on the server machines - Certain SIEM solutions do not properly support remote collection of OS or application logs so they need a server side agent to do the job. On the other hand, most business critical systems are tightly controlled and do not allow for additional resident programs to be installed on the system for the risk of possible performance or reliability issues
• Are there any custom applications that generate logs that needs to be collected by the SIEM? - The organization may require that the SIEM also collects and parses such logs, but proper parsing ability needs to be verified with a large sample of logs during a proof of concept run.
• Is there any international standard or regulation that is mandating the SIEM solution - whatever standard needs to be met has a set of predefined controlling reports that confirm compliance to the standard. You need to confirm that the SIEM solution can produce the needed reports.
• How long will you need to keep logs and conclusions online and offline? - data retention is key to such a massive collection of information. Typically, a SIEM system needs to be able to archive all historical events to external data storage, and preferably, the archival process should include an integrity control (MD5 or SHA1 hash) that guarantee that the logs haven't been tampered with while in archive.
• What type of processing and alerting is required?-
  

Proper answers to these questions will most likely eliminate the non-acceptable solutions, and will ease the evaluation process of the qualifying shortlist.

Talkback and comments are most welcome

Related posts
Real Benefit of Security Information Event Management

Security Information Event Management is the echoing buzzword in most industries these days. Banking, Telecommunications, Power and Energy - anyone and everyone is under internal audit and regulator scrutiny to implement a Security Information Event Management system.
But most Security Information Event Management implementations are rushed and placed only to shut up the auditors and to go on as usual. Since it's a compliance requirement, the Security Information Event Management salespeople very rarely address whether the customer makes proper use of the solution, and whether this solution brings benefits to the company.



The common issue
SIEM is a Security Officer tool, but since it tightly integrates with IT equipment, the SIEM implementation is usually left to IT departments. The issue with this is that IT will approach the implementation from a purely technical aspect: how to properly connect the IT equipment to the SIEM system.

Once the SIEM system is collecting audit logs and events from all required IT elements, the job is done. At most, a retention policy and archiving is also done by IT, and the story ends there.

The real benefit
Any SIEM system is simply a large database collecting massive amounts of events. But if one does not use these events, the system is placed there just as a form, and brings only costs to the company. Here is what you'll need to set-up to achieve benefits of a SIEM system

1. Choosing what is most important to be alerted about - While some automated alerts and analysis are available within all SIEM systems, the generic alerts are rarely well matched to a company. For example, a generic alert may be triggered by consecutive failed attempts followed by a successful logon, but may not be triggered on a configuration change of a firewall. The first event was merely an employee trying to remember his password, and the config change of the firewall just opened up your network to some attack
   
2. Alerting the proper person/team - The alerting means nothing if the alert does not arrive to the proper person to react in the fastest possible time. A 'transaction log is full' means little to a network admin just as SYN flood may mean absolutely nothing to the DBA. And both will mean not too much to the head of the department, if one chooses to send all alerts to the manager.
3. Creating and using the proper reports - Some SIEM systems come bundled with reports, other sell the reports as packages. But the vanilla flavour reports may not always be useful to the organization, so the correct report definition should be prepared and implemented during the SIEM implementation. This way the company will know that these reports are to their specification, and even more, that the data needed for this report is collected by the SIEM system.

Talkback and comments are most welcome

Oracle owns Sun. It moved to acquire the failing giant ahead of IBM and now it has access to a great amount of installed base of Sun servers. But what will Oracle do with a hardware company, and what will remain of it after Larry Ellison is done with Sun?

• Hardware - Oracle has it's R&D focused on databases, and to some extent on underlying operating systems. But Oracle does not want to meddle with expensive chip research just to maintain the SPARC platform. So servers division will go on sale to HP, IBM, EMC, Dell or some venture capital firm - lock, stock and barrel.
• Solaris - A wonderful OS, leader in many platforms. Oracle will want to make it's DBMS one-click installable on an empty machine, so Solaris for Intel will probably be the weapon of choice for this move. But in the process, Solaris will become an embedded
• MySQL - a possible casualty of the RDBMS war - Oracle will need to position this product carefully, to be less competitive with Oracle RDBMS and more competitive to embedded databases and free competition. If Oracle cannot do this, they'll most probably let MySQL die of age by simply not developing it any further.
• Consulting division - Some will be cut-off, some will become Oracle consulting and integration, to take even more off the high-margin integration consulting business
• Open source initiatives - THE BEST PLACE for developer breeding. If Oracle retained any smarts, it will maintain the strong support to open source, but steer it towards Oracle as development platform.
• JAVA - The weapon of mass destruction for Oracle - Just like open source initiatives, excpect that Java will continue to flourish - simply because Oracle wants more and more software that will use their databases.
  

In any case, things won't be the same. It is sad to see another one of the high quality system giants go.

Related posts
HP partners with Sun - Anybody remember Digital?

Online or cloud backup was one of the buzz words of cloud computing, and was actually leading the wave in terms of commercial implementation. Hewlett-Packard had it's Upline service, Yahoo had it's Briefcase, IBackup is going strong. But the market for online backup is still quite volitile.

For instance, HP has decided to shut down Upline, without much explanation to the customers. It went down on March 31, 2009. Oh, by the way, Yahoo closed shop at Briefcase on March 30, just a day earlier!

In the meantime, the big players are repositioning: EMC purchased Mozy - an online backup startup, and is pushing the service strong. And there are still new players on the field - COMODO has just announced their online backup service. And we are hearing that Symantec is also going into the online backup business!

With all these events, several questions regarding the entire Online Backup solution surface from the murky deep

• Who uses whose infrastructure? - the simultaneous closing of two major services (HP Upline and Yahoo Briefcase) may be a simple coincidence. But, on the other hand, it is a 'cloud' service, thus one service may outsource it's physical storage to another vendor. This leads to all kinds of unanswered questions like
• Who else has access to the backed-up data?
• Is the advertised availability actually achievable?
• Can we loose the backed-up data if the outsourced provider fails financially?
  
• Is your online backup actually safe? - While technical security measures can be implemented and documented, corporate decisions fall way outside of the scope of the service. And corporate decisions may include layoffs, selling of assets, closing of divisions, even selling of the entire company. And in such conditions, the service provider's employees could care less about some Joe Average's online photo collection or sales reports
  
• Can you define a long term data retention policy and rely on online backup to meet it? - HP is a HUGE company. And it failed to deliver a long-running service. One may discuss that HP is primarily a hardware vendor, but nevertheless, as a large company is always interested to present itself as a serious long-term partner. And yet, it closed it's service. So, who can tell what will happen to the other Online Backup service providers?
  
• Which service provider is the right choice for Online Backup? - Again, HP and Yahoo are large, and closed up shop. Other service providers are all over the place: From start-ups, through venture capital funded firms up to large players who purchased smaller ones. Which one will prove to be the best, and which one will actually deliver on the promise
  

There are no definite answers to these questions. But in a time of economic instability, the services and service providers can find themselves in all kinds of trouble , relying on online back-up without a second option feels a lot like gambling. And gambling on technical, financial and business level.

Talkback and comments are most welcome

Related posts
3 Rules to Prevent Backup Headaches
Cloud Computing - Premature murder of the datacenter
Know the Difference - Backup vs. Archive
Security Concerns Cloud “Cloud Computing”

Hewlett-Packard and Sun will announce details of “their newly expanded partnership agreement”. Might this be a step towards a merger?

The analysts list a number of of mutual benefits for both companies, with two major elements

• Major benefit for Sun - Cashflow
• Major benefit for HP - Enterprise level architecture and OS technology
  

The older readers may remember a company with great technology that got eaten by a PC vendor.
Compaq got its hands on Digital hoping to benefit from it's technology and expertise. At the end, they didn't seem to know what to do with it until HP acquired Compaq.


Sun also has great technology and is also down on it's financial luck.
But is HP actually prepared to reap the benefit of the great technology that Sun brings?


History teaches us that HP had several shots at large enterprise and somehow managed to miss most of them:

• HP is supporting 3 large enterprise platforms, which obviously puts a huge strain on their interoperability and compatibility design. Also, so many platforms mean that the buyers are easily confused:
  
• It's own series of CPUs (PA-RISC) and Operating System (HP-UX) that is designed for large enterprise - The Superdome
• The acquired Alpha CPU based servers with TruUnix64 or OpenVMS which are still being supported as legacy systems
  
• The Integrity series with Itanium CPUs supporting several OS platforms
• HP bet on Itanium1 and missed an entire generation when Intel delivered a chip of mediocre power and there was no major enterprise software support for it
  
• HP didn't manage to develop a native middleware platform for their hardware, and relies on Sun, IBM and third party vendors to deliver such platform.
  

With such a track record, one needs to be worried about the realistic benefits and outcome of this partnership
In the long run, we just hope that Sun survives as independent high quality vendor for enterprise solutions.

Talkback and comments are most welcome