I have been reading about the upcoming retirement of support for the Microsoft Server 2003 operating system (OS). One author felt that organisations will probably mismanage the retirement of the OS, like many did with the retirement of Windows XP.
It led me to reflect on the management and operational processes used by IT Departments to keep the lights on, the effort needed simply to achieve that base operational goal.
In a small-to-medium sized IT Department, simply asking to see the network and system diagrams and associated build or as-built documentation can be an entertaining process. You will be able to watch the question circulate through the department like a hot potato before it drops with a thud to the floor.
So should you push further and ask if they know what makes their network operate? On the journey towards IT documentation maturity, that kind of question can expose where an organisation is at.
It's common for IT departments to have a system that leaves local IT professionals unclear about what it even does or how to fix it beyond a server restart. It makes me wonder if the risk of failure has been reviewed in line with business requirements.
Missing documentation in IT, for me, tends to highlight deeper issues. Many IT departments are stuck swapping light bulbs with other light bulbs. I think it is very easy to lose sight of the less sexy parts of IT, such as keeping your documentation current.
Making our task even harder, we also have to manage security, cyber-attacks, the Privacy Act, the Australian Signals Directorate and more, all with our limited staff resources. What a challenge!
Do small-to-medium organisations really understand IT requirements beyond keeping the lights on and keeping the organisation secure. Are we so busy looking at clouds that we forget to update our operational documentation?
- Is this something that needs a committee or working group to assist with understanding?
- What can we do about this problem?
- What is the foundation of this as an industry issue?
In my view, the starting point is Asset Management because we are talking about a process that develops over time.
It is worth keeping in mind that Asset Management is not just about the accounting department needing a record of when you purchased or retired hardware. It’s also about more than knowing when you are using equipment beyond its intended life span or deciding if you should lease or purchase the equipment in the first place.
Assets can take several forms. They can be broken down to three main areas; hardware, software, and data, which may be in the form of Intellectual Property or confidential information.
Knowing your assets and maintaining a current and valid inventory is the beginning of many important IT processes. While it's not a glamorous function, from a governance and risk perspective, it is a process of responsible business. And, if you dig a little deeper, you can start realise additional value.
Let me validate that last comment:
- From an operational perspective, Asset Management helps identify assets that are coming to the end of their support cycle, have reached maintenance or vendor end of life, or that simply need to be replaced. (This is basic light bulb maintenance.)
- Knowing your assets is a good primer for a patch management process as it maintains useful information like Make, Model and OS or Firmware version. If you link this to your Risk Management process, you can look at how to schedule maintenance upgrades without conflicting with other key business operations.
- All documentation should be linked to the assets in the process or system, it will help keep all documentation current.
- From a network security perspective, a list of assets helps maintain access control of devices and of who has access to data on network shares. It can also be used to identify an asset’s owner.
- A good risk management process starts with knowing which assets are used by each business process.
- An accurate asset list will be valuable for data protection and backup architecture, ensuring you have included all your hardware, software and data assets in a business impact analysis, and defining your recovery point objective and maximum allowable outage.
- Having the detailed assets specifications can then be used in the business continuity process for understanding your requirements.
- Asset dependencies can be included to ensure data and informational assets can still be accessed.
These are some of the high level basics of asset management. Hopefully you can see why I think it is an important part of the daily business of IT. This is not an exhaustive list, it is meant to tickle the grey matter so you start to think about the importance of your company’s assets and the maturity level of your own asset management and documentation program.
Once you have your assets listed, you can look at any existing IT documentation to perform a gap analysis of what is missing. Remember, asset management and IT documentation is a journey. You need to ensure it is worked on little by little each day.
As you listen to all the talk around IT security and protecting your organisation’s crown jewels, have think about how will you implement systems and controls when you have all your assets listed and managed. Think about how much easier it will be to identify what needs protecting and what the business impact of each asset might be!
This article is brought to you by Enex TestLab, content directors for CSO Australia.