After 12 years in this industry I really wish I could claim that the problems we saw at new customers this year were different from those we've seen for the past years...but unfortunately that's really not the case.
First, there was the customer that contacted us after experiencing a BSA audit having paid out hundreds of thousands of dollars in fees and consulting dollars (lawyers, experts, etc). We assisted them in determining what they needed to purchase but they still wouldn't invest the small amount of money to put in an appropriate Software Asset Management (SAM) program (tracking software, processes, policies and product use rights education) or even consider outsourcing this issue.
Second, the customer who wanted some help negotiating a new volume licensing agreement. Unfortunately, when they had implemented their SQL Server 2005 environment with redundancy they failed to consult with an expert on product use rights (PUR's) so ended up implementing a solution requiring them to have duplicate SQL Server Enterprise processor licenses...a very expensive solution that could have been avoided with a quick phone call or e-mail.
Third, there was the customer who wanted our help in performing their Microsoft true-up. They had discussed their server virtualization project with their reseller in connection with their VMWare needs...but the reseller never asked about their actual server licenses. The 20 Windows Server Enterprise licenses they needed to purchase came as a complete surprise.
The list goes on...
The lesson to learn here is this: In Software Asset Management, spending a little money by having an expert on retainer can easily save ten-fold on your investment. Stop relying on internal staff who do not have the time or the resources to know the current PUR's on all your products, and don't take the word of anyone (including publishers, resellers or consultants) unless they back it up with publisher documentation.
I hope your 2008 is full of the positive rewards of an effective SAM program!
Friday, December 28, 2007
Thursday, October 25, 2007
Software Asset Management – A Regulatory/Industry Compliance Perspective
Software Asset Management (SAM) not only makes good business sense (lowers cost of software ownership, is integral to good security and enhances the productivity of technology workers) but it is also a key component in most of the regulatory and industry compliance requirements facing businesses today.
OK, I stretch on a few like HIPAA and Gramm-Leach-Bliley (GLB)…you can technically comply with these without SAM as long as you have hardware asset management, but still – you need to know where your computer assets are, who has access to them and be able to restrict what data can be loaded onto them.
But for Sarbanes Oxley (SOX) and the Payment Card Industry (PCI) Standards, it goes beyond that to actual SAM.
For SOX, there is a COBIT™ control objective which loosely states “Ensure that only appropriate software is installed in the environment”. Well, if you take that apart (which your auditors do…) then “appropriate” would mean (a) that you know what is appropriate and what is not, (b) that you have this documented somewhere, and (c) that it is licensed correctly. Additionally, to prove that you comply you need to be able to show what is installed in your environment and prove that you have a process that is documented and followed for periodically checking this information.
For PCI, you need to maintain a vulnerability program which has two requirements: (1) use and regularly update anti-virus software and (2) develop and maintain secure systems and applications. Both of these requirements come with a list of required items but basically it comes down to being able to ensure that every system has the most up-to-date virus protection and the latest approved security patches for all applications running on those systems. How do you ensure this information if you (a) don’t know what’s installed and where, and (b) don’t have a way of verifying what patch level it is at?
SAM makes good business sense, and it is required by many of the major regulatory/industry compliance requirements…so why are so many companies still avoiding it? Why the piecemeal approach that I see so often in the business place? Why do CIO’s and CFO’s eyes roll back in their heads when you mention SAM? I realize IT staffs are frequently overloaded and often do not have the necessary current information to maintain a SAM program – but isn’t that why we outsource?
Would love your insights…
OK, I stretch on a few like HIPAA and Gramm-Leach-Bliley (GLB)…you can technically comply with these without SAM as long as you have hardware asset management, but still – you need to know where your computer assets are, who has access to them and be able to restrict what data can be loaded onto them.
But for Sarbanes Oxley (SOX) and the Payment Card Industry (PCI) Standards, it goes beyond that to actual SAM.
For SOX, there is a COBIT™ control objective which loosely states “Ensure that only appropriate software is installed in the environment”. Well, if you take that apart (which your auditors do…) then “appropriate” would mean (a) that you know what is appropriate and what is not, (b) that you have this documented somewhere, and (c) that it is licensed correctly. Additionally, to prove that you comply you need to be able to show what is installed in your environment and prove that you have a process that is documented and followed for periodically checking this information.
For PCI, you need to maintain a vulnerability program which has two requirements: (1) use and regularly update anti-virus software and (2) develop and maintain secure systems and applications. Both of these requirements come with a list of required items but basically it comes down to being able to ensure that every system has the most up-to-date virus protection and the latest approved security patches for all applications running on those systems. How do you ensure this information if you (a) don’t know what’s installed and where, and (b) don’t have a way of verifying what patch level it is at?
SAM makes good business sense, and it is required by many of the major regulatory/industry compliance requirements…so why are so many companies still avoiding it? Why the piecemeal approach that I see so often in the business place? Why do CIO’s and CFO’s eyes roll back in their heads when you mention SAM? I realize IT staffs are frequently overloaded and often do not have the necessary current information to maintain a SAM program – but isn’t that why we outsource?
Would love your insights…
Thursday, September 13, 2007
Common Ways a Company Becomes Non-Compliant
Over the years I've worked with a number of companies and what has become obvious to me is that - it is rare that a company knowingly pirates software.
So, how do so many companies become non-compliant on their software agreements?
1) Lack of proper processes (and adherence to those processes) for software acquisition, deployment and retirement.
2) Lack of a good asset inventory tool that will accurately and easily report on what is installed.
3) Lack of records of what is owned.
4) Misconception or lack of knowledge of product use rights.
5) Misconception or lack of knowledge of volume licensing agreement rights.
Of all of these, I find the last two to be the most universal and it's a combination of misconception and lack of knowledge. Of the two I find misconception the most dangerous...because the company thinks that they're doing things right so they never ask for help.
How do the misconceptions happen? Generally, through outdated knowledge or guesswork.
Some things to be aware of:
1) Different use rights exist for different versions as well as different forms of acquisition.
For example, Microsoft 2007 software (Office, Server, Operating System) acquired OEM normally does not allow for downgrade; however, if acquired through Open, Select or Enterprise it normally does allow for downgrade. This was not always the case, in the past it had been allowed...was it allowed when you did it? Reference - http://download.microsoft.com/download/d/2/3/d23b9533-169d-4996-b198-7b9d3fe15611/downgrade_chart.doc). How were you planning to handle those OEM Office 2007 that are coming in the door? Were you going to downgrade those to 2003 until you're ready to upgrade?
2) Test and Development servers need to comply with product use rights same as Production.
3) Your Developers may have the "Professional" version of the software for development purposes but not be licensed for those for business use - be careful what's being installed on their production machines.
4) Vendors selling you a solution dependent upon another companies technology may not always provide you with full/accurate information about the licensing requirements...do your homework.
5) Client Access Licenses - in general if you're using the resources of a server, you need some form of client license for each user/device. Watch this carefully, it's the most common problem we find.
Just to name a few...
So, how do you keep up and still do your job? Frankly, you don't. You bring in professionals to educate you and provide you with documentation from the publisher supporting that education (do not rely on anything else...if a problem comes up, you're the one holding the bag) which you retain in a centralized location until those licenses (and their future upgrades) are no longer in use.
Questions? Comments? Would love to see them...
So, how do so many companies become non-compliant on their software agreements?
1) Lack of proper processes (and adherence to those processes) for software acquisition, deployment and retirement.
2) Lack of a good asset inventory tool that will accurately and easily report on what is installed.
3) Lack of records of what is owned.
4) Misconception or lack of knowledge of product use rights.
5) Misconception or lack of knowledge of volume licensing agreement rights.
Of all of these, I find the last two to be the most universal and it's a combination of misconception and lack of knowledge. Of the two I find misconception the most dangerous...because the company thinks that they're doing things right so they never ask for help.
How do the misconceptions happen? Generally, through outdated knowledge or guesswork.
Some things to be aware of:
1) Different use rights exist for different versions as well as different forms of acquisition.
For example, Microsoft 2007 software (Office, Server, Operating System) acquired OEM normally does not allow for downgrade; however, if acquired through Open, Select or Enterprise it normally does allow for downgrade. This was not always the case, in the past it had been allowed...was it allowed when you did it? Reference - http://download.microsoft.com/download/d/2/3/d23b9533-169d-4996-b198-7b9d3fe15611/downgrade_chart.doc). How were you planning to handle those OEM Office 2007 that are coming in the door? Were you going to downgrade those to 2003 until you're ready to upgrade?
2) Test and Development servers need to comply with product use rights same as Production.
3) Your Developers may have the "Professional" version of the software for development purposes but not be licensed for those for business use - be careful what's being installed on their production machines.
4) Vendors selling you a solution dependent upon another companies technology may not always provide you with full/accurate information about the licensing requirements...do your homework.
5) Client Access Licenses - in general if you're using the resources of a server, you need some form of client license for each user/device. Watch this carefully, it's the most common problem we find.
Just to name a few...
So, how do you keep up and still do your job? Frankly, you don't. You bring in professionals to educate you and provide you with documentation from the publisher supporting that education (do not rely on anything else...if a problem comes up, you're the one holding the bag) which you retain in a centralized location until those licenses (and their future upgrades) are no longer in use.
Questions? Comments? Would love to see them...
Subscribe to:
Posts (Atom)