An interesting site with blogs about IT audit and security
Risk3sixty refers to itself as providing “insights on information risk management, cybersecurity, IT Audit, and Information Assurance”. Christian Hyatt is the lead author and his posts are typically quite short (unlike some of mine).
One caught my eye: “Application Risk Management”, from April of this year. It suggests three steps:
- Build an application inventory
- Assess the level of risk for each application
- Select projects
In such a short post, it is impossible to be anything but high level, possibly even simplistic. However, let me point out a couple of issues.
- In these days of cloud and mobile, it can be incredibly difficult to get a handle on all of the applications used by management across the enterprise to make decisions, process transactions, and so on. Any inventory you build is likely to be out of date within the month.
- The level of risk should be assessed based on the potential for a failure (of or relating to the application) to affect the operation of the business and achievement of enterprise objectives.
Expanding on the latter point, is it better to build the risk assessment based on an inventory of applications (which is a ‘bottoms-up’ approach) or by taking each enterprise objective and considering whether a failure in an application would have a significant effect (which is a ‘top-down’ approach)?
My personal view is to place more attention on the latter, but I can understand the desire to supplement it with a bottoms-up approach.
As Christian asks: how do you assess risk relating to applications?
I welcome your comments.
Leave a Reply
Norman Marks on Governance, Risk Management, and Audit 
That’s a great point about top down versus bottom up apprach. I think the bottom up approach is helpful when you’re trying to take an inventory of your assets and get an idea of what type of digital footprint you’re dealing with – especially from a cyber-risk perspective. Also to understand where critical data lives and which applications are sharing data with each other or third parties. It’s kind of a good opportunity for a company or sector to take a step back and take stock. It can also drive the top down perspective when it comes to audit project selection.
However, as you mentioned, a complete list like that can never be 100% complete and will quickly fall out of date. I like to take a top down approach to focus my efforts then gather the details about the environment.
The generation of the application inventory list should be system generated and automated. Then automated controls should be put in place to essentially freeze it via a Configuration Manager (e.g. SCCM), restriction of administrative privileges, and Software Restriction Policies & Applications (e.g. AppLocker).
From here, I believe the next smart step is to enact risk mitigation and disaster recovery controls around the business critical applications and policies. This results in a reconciliation of both the top down and bottom up approaches described in Norman’s post.
Shane, will this automated inventory include all apps in use for mobile and in the cloud?
Norman, you could control application installations on mobile apps by using tools such as airwatch or others. Regarding the cloud, anything that is integrated with enterprise apps, has data feeds, or integrated with active directory could be controlled and inventoried. That also relates to third party risk management. (You can inventory those by running a list against accounts payable on a periodic basis to see if any new cloud vendors pop up.) This level is probably the biggest risk because of the amount of connection and integration with key processes and data.
The apps that would be more difficult to catch are those that a user or department can sign up for without much integration – like Dropbox or similar.
Christian, there are problems limiting apps on the personal devices used by many managers and executives. In time, IT’s knowledge of which apps are in use will diminish. However, a top-down approach should catch many if not most. So if you like the bottoms-up approach, I suggest supplementing it with some top-down work. How do managers and executives run the business?
Yep, I agree totally. Definitely don’t want to lock down users from doing their jobs. (Too much security) You can leverage those type of apps to keep track of what’s out there. Top down should be the basis with tools to enhance decision making via solid information.
Great conversation, Norman. One I think most companies are having or should be having with their security guys.
One application that doesn’t get sufficient attention is user-defined analytics, especially mobile analytics. Sources of risk include not only the integrity of the data, but the use by the manager or executive.
These applications are used to drive major decisions. If the analysis is incorrect (whether user or other error), the impact can be huge.
In the past I have been involved in a large project to make a Dutch department comply with regulation on information security that – at that time – stated that every information system (application) should have an information security plan based on risk analysis.
Although it was in the ‘pre-app’ age, I believe some lessons learned, still apply.
Because of the size of the organisation, it had different systems in different domains (logistics, finance, HR, etc.). Some systems formed a chain of systems.
We did start with an inventory. This was needed to plan and manage the entire project (resources needed, follow progress, etc.). But although it was in the same time an inventory had been carried out to deal with the ‘millennium bug” and previously an inventory had been carried out to support a platform migration, no inventory appeared to be complete. While performing risk analyses, systems owner still came up with other systems.
Nevertheless, you should have an inventory. Many methods start with executing a Business Impact Analyses (BIA) to define the level of security needed. Our experience was that after the BIA you should stop and start a consolidation fase. If not, systems with the same kind of functionality or even systems within a (logistics) chaine would receive different score on the BIA and would have different (mostly to high) levels of security.
[People tend to give their system higher scores as they think they are more important.]
Without an inventory and good planning all systems will be treated as silo’s, which they are not.
Needless to say that this deals with security in the broad sense, so not just the chance for material errors in the financial reports.
Hi Norman,
Using “bottoms-up” as the sole approach will most likely include applications that may exist in the environment but don’t play a role that is significant enough to warrant the resources necessary to evaluate, test periodically, or monitor.
So, in regard to risk mitigation, and the efficiency and effectiveness of the audit team, starting with the “top-down” approach makes a better starting point. As you said, taking each enterprise objective and considering whether a failure in an application would have a significant effect needs to be performed, but the actual applications that qualify for this objective will still need to be fleshed out. So, to some extent, the end result will be an inventory of applications to “select projects on.”
Yes, you are correct. It can be incredibly difficult to get a handle on all of the applications used by management across the enterprise to make decisions, process transactions, and the environment is ever-changing. However, without maintaining accurate knowledge of high-risk applications in use at any particular point in time, you’ll never satisfy the enterprise-level objectives.