The creation and maintenance of an Information Security Management System (ISMS) as prescribed by ISO 27001 requires a thorough understanding of all the entry and exit points through which data can pass - from there, appropriate measures can be put in place to offer the degree of control appropriate to ensure that information is being properly managed, and that you and your company have faith in your Statement of Applicability (SoA).
Pivotal to understanding these points of ingress and egress is the software which transmits information, and how robust it is to the challenge. This is where Software Asset Management (SAM) can help: Any SAM framework worth its salt should have a Supported Software Catalogue in place to help manage the IT estate. Essentially, this is the list of software required to run the company, and while it might have been crafted with Software Asset Management goals in mind, the addition of a few strategic columns could easily serve Information Security as well as SAM. The following paragraphs are offered as food for thought when looking to bolster your Supported Software Catalog (SSC), but before then, here are a couple of points to consider when implementing your SSC:
If you have a policy to create and maintain a Supported Software Catalog, then it is worthwhile capturing the business and IT drivers you expect the catalogue to support - this may sound obvious, but it's surprising the columns and stakeholders that can be revealed if such an exercise is periodically undertaken. Please note: A Supported Software Catalog should not be viewed as a replacement for a Software Asset Management Suite; wherever possible, getting away from a spreadsheet for license calculations should be the primary goal of any SAM Manager as it will fail to scale, and could be open to manipulation in support of a particular individual doing a better job than objective reporting might highlight.
It's not enough to know what columns need populating within a Supported Software Catalog, of equal importance to SAM and the business is to know and understand who owns the data that you expect to see in those columns.
Knowing which systems are used to house data is equally important as knowing who owns the data. Don't assume that all relevant data will be housed in the SAM Suite; it won't.
Another consideration to give serious thought to is where the SSC is going to be housed. Creating a dedicated database for such a data structure would not be the worst idea, as trying to shoe-horn non-core activities into ERP systems or inventory systems could adversely affect their performance as well as hike up consultancy fees to get such systems to perform in a manner they were not designed to do.
True appreciation of stakeholder requirements can be demonstrated by analysing which views of data are presented to various individuals as they might use the Supported Software Catalogue. End users will only need to see enough data to inform them of their software request choices; procurement will be more focused on data that supports the management of contracts and licences; Information Security will be concerned with product release data, and when install files/packages were last updated.
Stakeholder roles within the company may limit data from a Column/Y approach when using a Supported Software Catalogue, but of equal importance is that of deciding which rows/software titles are available to certain staff members. Typical end users should not have visibility of ERP/CRM back-end software titles, and equally, high-end coding packages will offer little value to a standard user in the accounts team. Try and balance your title visibility with your stakeholder's view of IT, but be mindful that an overly detailed plan restricting visibility of certain titles to certain users, could place a management overhead on whoever is looking after the Supported Software Catalogue.
To ascertain who needs access to what, we can borrow an exercise from Agile, and use the following use-case generator to determine data visibility:
"As a <insert job role> I need to be able to see <insert data here> so that I can perform <insert job task>"
These five columns will offer a surgical definition of the software titles on your estate. The first four columns will come together to offer a crystal-clear definition of any software that might be requested. Too many end users will operate under the mistaken belief that there is only one edition or release of software, or not be aware of the licensing problems that arise in mixing up choices. At best, users will most likely need to see the first four columns mentioned above, perhaps even with the classification/type of the title, and whether the title meets your "buy/hold/sell" requirements.
The SKU value will be of greater significance to procurement, once they receive an approved software request from the end user - The SKU will have little to no meaning to someone outside of IT/SAM, but should be associated with the request when it arrives to support the intended purchase.
Classification/Type & Description:
In the world of desktop computing, many requestors are influenced by what their colleagues are using on their laptops and pc's. Consequently, "Desktop envy" has been known to promote the installation of many software titles, regardless of whether they are needed to complete work. One column that can help mitigate the rise of such requests is a classification/type field, allied with a description field also. This will help end users gain a very clear understanding of what the software title can achieve, rather than base any requests on what they think the software can do.
A simple description of software titles will also aid to comprehension of what titles are needed to aid productivity; which could even impact whether a purchase is executed. It has been known for staff members to request a database license because they (wrongly) believe that such a licence is needed to be able to communicate with another database (as opposed to a Client Access Licence).
Many end users (and indeed, some IT professionals) remain naïve when it comes to understanding the cost of software, and so trying to convey that at the point of ordering will begin to bring home the expense against any perceived productivity benefit. A wider discussion also needs to take place on how software is managed within your company, as this could influence whether or not price is included in the Supported Software Catalog (and indeed, what price might be quoted). If your business is interested in recycling software, then does the existing financial model within the business support recycling? Some budget managers could get quite irate if they make a purchase in good faith, only to see that after 90 days of non-use for an installation, their software is removed and the license falls into a central pot for re-use - and pot-luck for them to ever get the installation back.
Clearly, some thought needs to be applied here, and perhaps this is where the next column can lend some clarity to the recycle-re-use scenario above.
Scope (Boundary of Deployment)
If our afore-mentioned budget manager does not wish certain titles to get recycled, then perhaps he/she could do worse than raise such installations as separate/regional line items within the Supported Software Catalog, so that only staff covered by his budget can access/see that software. It might well be that the title mirrors an existing software title on the catalogue, but at least he/she knows that if a recycling policy is enforced, the spare license will only go back into his/her pool for re-use by that budget domain at a later period.
In a wider context, Scope (Boundary of Deployment) is yet another field of data that could assist an end user in choosing a title. If staff find themselves beyond the building/ business/ geographic scope that the license permits, then they will have to go through additional steps if they are committed in obtaining that software title.
Green/ Amber/ Red
This categorization is subjective, and open to greater interpretation than perhaps the other columns within the Supported Software Catalog we have seen so far. Ideally, end users should only see software titles that have been categorised as Green as these are the titles you want them choosing. Amber titles might be instances of software that are still live on the IT estate, but have a superior (Green) instance you wish end users to request. Red titles are those software titles that have been deemed end of life and should be ear-marked for removal if they have not already been removed. It is recommended that red titles are not displayed in any views to those people requesting software, as it will only confuse matters when coming to select a title for installation.
Further graduations between Green/ Amber/ Red might be required for your company, and so should be added accordingly.
Testing date & Tested by:
Alongside a Red/Amber/Green assessment of software titles, is knowing when software was tested, and who performed that test. Clearly, testing routines will vary greatly depending on the role and scale of software being tested.
Company Tipping Point:
It could be that you can derive a smarter name for this column, but this is the count (by install) of when titles should be considered for Enterprise-wide contracts. Here we can help Procurement and Vendor Management departments, by being able to notify them of when certain titles have reached a point at which it makes sense to engage a vendor/reseller and formally determine whether a volume agreement would make better financial (and compliance) sense. Conversely, it could also assist Procurement and Vendor Management when titles have slipped below such a threshold, thereby relegating a vendor away from dedicated status.
From a SAM perspective, the inclusion of a license metric is an obvious choice, and will undoubtedly help non-SAM personnel understand HOW a license is deemed consumed. Product Owners too, will benefit from understanding how their software titles are used within a company with such an at-a-glance guide.
The Product Owner is the champion within the company for the use and deployment of a software title/titles. Key stakeholders within Information Security, Procurement, Helpdesk and end users will have a ready port of call if they need to approach a specific individual about how a given title should be used, whether trials could be provided, and if the software product contains certain features or capabilities that could improve productivity.
This column might be deemed optional depending upon the size of your organisation, and also the number of software titles you have in your catalogue. Certain titles will necessitate direct deals with the software vendor, others might stipulate working through a reseller, and so Procurement would oversee any acquisition. Wherever possible, any purchases should be tied back via a central system, so that trend-analysis will support strategic decisions pertaining to whether company-wide contracts are to be adopted, or if particular elements of your business seem to be rubber-stamping software requests instead of checking to see whether a spare license in the license pool could have prevented a purchase.
Certain titles and certain purchasing routes may also influence which company you do business with. Equally, other titles could mandate that your company can only deal direct with a software vendor.
File Installer/Package Name:
If a purchase has been made in support of a request, and if the SKU value is used, this can be corroborated against the correct install file or package name. It's also recommended that a naming convention is used - solely re-using SKUs would not be intuitive, but neither would nicknames or casual terms as to what software is included in a package.
Date of last update of File Installer/Package Name:
Hotfixes and patches could result in release-variants of software - Information Security staff within your company will want at-a-glance guidance on whether installer packages have been kept up to date, and so could use a date last updated field as a first assessment of whether such packages are in step with the latest security upgrades required of software titles within the ISMS/SAM scope.
File Installer/Package Location:
Depending upon the size of your company, it may be that you have several locations for source files used in the installation of software and so it's important to be able to offer traceability from install, back to purchase and ultimately to request.
File Uninstaller/Package Name & Package Location:
Uninstaller files are not to be over-rated; if you wish to implement a scalable recycling and removals policy/process, then these files will be needed to execute on those removals. Also, a point worth noting for our CMDB colleagues; if such removals alter the state of a CI schema, make sure such changes are reflected in those schemas; as a comparison between the schema and the device with the removed software might result in installing software that had previously been removed in good faith.
Upper License Pool Limit:
Trend analysis relating to installs and removals will offer upper and lower levels of use for software titles within your company. The point at which your organisation no longer needs to buy software titles should be retained in this column so that procurement can be informed when to cease purchases because the license pool is getting too large.
Lower License Pool Limit:
Converse to the previous paragraph, when the lower limit of a license pool is reached, Procurement can once again be informed that purchases are ok to be instigated once more for software titles.
An argument might be made that much (if not all) of the information above should be contained within the SAM Suite - and while it would make an excellent repository, access to that information needs to go wider than the typical access granted to a SAM Suite. We return to our view paragraph (above) whereby many stakeholders will need visibility of the data, but won't necessarily need to edit the values.
The preceding columns are advisory, and we would welcome your thoughts on what other values might benefit your peers in the management of software and IT in general.