Information Security Governance Model

Based upon my experience at two organisations where I recently worked, I developed an information security governance model.

The key message is that you should not only detail ISO 27001/27002 controls on the corporate level but also for each operational team (group of people with similar expertise) so that people at the work floor know what their responsibility is. In the end, they are the ones actually doing the implementation and execution of the security measures. Generally, corporate level controls are still too abstract for the people on the work floor and not all controls apply to them.

Common mistakes in security governance

• Security is seen as something of the security officers; security officers have to design objectives for the security controls
• Even if there were no security officers, the organization should still be in control of its security.
• Security is too big, too widespread and relies on too many business and technical skills for security officers to cover this all; the only way to deal with it is make sure that the business and technical specialists know their responsibilities and deal with security risks.
• Security responsibility is assigned to a single manager only (or to managers only)
• Many security issues relate to low level, technical and sometimes very complex issues; the managers generally lack the knowledge to recognise risks or specify which control measures to take.
• Employees do not know what their responsibilities are.
• ISO 27001/27002 control objectives are specified on the corporate or division level only.
• This gives insufficient guidance to the people on the work floor; you need to specify control measures in such a way that employees know what their responsibilities are.
• Reliance on the audits or security officers for the C (check) of the PDCA.
• Operational teams should do their own checks and team managers should use these for their Act and Plan; audits and security officers checks should be additional; team managers should be in control.

Consequences / symptoms

• Security officers are forcing solutions onto the operational teams or are implementing solutions themselves.
• Security officers are alerting management to risks but management does not know what to do with them and therefore forget or ignore them.
• Unnecessary conflicts between security officers and operational teams.
• Implementation of security controls are implemented in a rush just before an audit.
• Audit issues have been assigned to managers but tasks have been watered down so much that at the operational level nothing happens.
• Everyone is responsible, so no one is responsible.
• Managers have been assigned a responsibility but have no mandate to get things done in other teams where various aspects of the measure have to be implemented. Therefore the implementation of the control stalls.
• Issues have become so urgent that security officers get the attention of the CEO who enforces to put a control in place urgently, disrupting business and IT operations.
• Decisions are made based upon emotion instead of rational analysis of risks.

The governance model in summary

• Organise the PDCA cycle not only at the corporate level but also on the divisional and operational level.
• Formulate the ISO controls for each operational team and define what their specific security responsibilities are. Let the teams do a periodic self assessment supported by security specialists.
• Organise a periodic management review at the divisional level. The team managers bring the reports by their own teams and appropriate actions are formulated. It might be that projects need to be started and as such you probably will have a security programme of projects.
• Because multiple teams can have a responsibility relating to a specific ISO control, someone must make sure that the sum of all those responsibilities adds up to the total what the organisation needs. The execution between teams might also need to be coordinated. For that you can group ISO controls in processes and assign a process manager to coordinate all the controls per process. One way to group the ISO controls is, is according to the ITIL processes.

I have detailed the model in a powerpoint presentation. If you are interested in the model, please contact me on platosrevenge@gmail.com and I will send this to you.

ShoppingApp

At Christmas I thought I had some extra time left and needed a new hobby. So I thought to pick up programming again. Making a shopping list for the weekly trip to the supermarket was something that could get a hand. I already tried to automate the shopping list creation process through Excel but there was still the problem to bring the list to the supermarket. Walking around to the house with a laptop wasn't very handy either.

I looked at some tools to build apps and ended up with Android Studio. I bought a book about Java and 2,5 months later, the result: the ShoppingApp.

Download and install the ShoppingApp from the Google Play Store.

Unfortunately it is Android-only.

If you see any improvements, you can mail to platosrevenge@gmail.com.

My ShoppingApp website can be found here: http://shoppingapp.bouman.net/

SDLC - Business versus IT streams

A model I created a long time ago.

 

 

	Business responsibility	Technology responsibility
	Investigation phase ·         Proposal business improvement opportunities.doc o    Proposal for initiating a project and use of resource to improve the business; initial business benefit indication; very high level cost/benefit analysis; indication on how to continue with respect to resources, involvement of people, etc. ·         Business strategy planning.doc ·         Business change management plan.doc
	[Management decision to continue] ·         Business resource planning for next phase ·         Priority definition ·         Assignment of business project manager	[Technology planning] ·         Technology resource planning ·         Priority definition
	Analysis phase ·         Business process analysis.doc o    business process diagram’s; data flow diagrams; includes automated and non automated aspects; IT opportunities; includes as-is and to-be versions; includes interactions with automated systems ·         Vision (scope statement).doc ·         Business case.doc, o    containing brief outline of following items: business benefit; cost/benefit analysis – business & technical / operational & project; resource requirements – business & technical x internal x external; high level indication of timelines and milestones; change management analysis	ICT Strategy planning ·         IT Strategy Analysis & Definition .doc ·         IT Enterprise architecture analysis & defintion.doc
	[Management decision to continue] ·         Budget provisioning ·         Resource planning	[Management decision to continue] ·         Budget provisioning ·         Assignment of technology project manager ·         Resource planning
	Business project management ·         Project plan.doc ·         Business requirements document (detailed).doc ·         Scope management plan.doc ·         Staffing management plan.doc ·         Communication management plan.doc ·         Project schedule.mpp ·         Risk management plan.doc ·         Quality management plan.doc   Business design and change ·         Re-organisation blue print.doc	Investigation phase ·         Exploration of technical options.doc o    potential technical solutions; high level cost benefit analysis, including project ROI and operational ROI; optional vendor quotes; technical & functional & data visualisation in schemas and text, taking technology enterprise architecture into account
	Business project management ·         Project status report.doc ·         Project status dashboard.doc ·         Meeting minutes, issue logs, etc. ·         Project change log.doc   Business implementation ·         User acceptance test script.doc ·         Training manual.doc	ICT project management ·         Project plan.doc ·         Scope management plan.doc ·         Staffing management plan.doc ·         Communication management plan.doc ·         Project schedule.mpp ·         Risk management plan.doc ·         Quality management plan.doc   System analysis & design ·         Business requirements (system requirements).doc ·         Information analysis.doc ·         Functional design.doc ·         Technical solution design (system architecture).doc ·         COTS evaluation.doc
		ICT Project management ·         Project status report.doc ·         Project status dashboard.doc ·         Meeting minutes, issue logs, etc. ·         Change requests.doc ·         Project change log.doc ·         UAT sign-off.doc   System development ·         User acceptance test script.doc ·         User manual.doc ·         Technology operation manual.doc2
	[Management decision] ·         Sign off	[Management decision] ·         ICT operations acceptance

 

 

 

 

Be careful with assigning more power to the CSO to improve information security

Information security has never been as important as now. It's being said and heard everywhere. But organisations should be cautious to translate this to more power for the CSO/CISO.

Information security is a complex matter and is all about risk management. Risks should be assessed daily throughout all levels of the organisations: business management, IT management, IT specialists and end-users. When a firewall expert makes decisions on how to configure a firewall, it is impossible for a Security Officer to participate. The same applies to when the business owner of an application specifies his requirements.

To make these security decisions, you take a variety of issues into consideration such as the perceived threat, the cost to mitigate, impact on usability or operational efficiency.

Information security is just one of the subjects that is being delegated down through the management hierarchy, just like for example financial responsibility.

The risk is that if a CSO and his team are assigned power, they will start telling the people in the organisation what they can and can’t do. And they will threaten staff with non-compliance and force them to follow rigid frameworks. Those others than might take a passive approach and will not take their responsibility and refer to the security department for taking actions. The relationship between Security Officers and the IT-team is in many organisations far from optimal. This has a negative impact on the actual security, even if you are compliant. Compliance does not mean that all is secure.

Specifically, because information security is so important, all employees and all managers should be made fully aware of their responsibility. They should be trained and should be guided with the process. Their effectiveness should be measured through personal KPI’s and team KPI’s. Audits will assist to measure the effectiveness of the organisation but audits and compliance should still be considered as a tool to assist with the objective of the organisation. And information security is only one of the objectives.

The Security Officers play of course a very important role. They can’t be made responsible for the security of the systems. Simply, because to achieve good security, actions should be taken spread out through the organisation that requires too much knowledge of too many technologies.

The Security Officers therefore should use the regulations and frameworks to guide the organisation through the processes, help them to check the status where they are at and provide recommendations for improvement. Of course, when they see a risk, they should not give in and still report the risk via an escalation path to management. But management then decides whether to accept the risk or to act.

If you need to improve your information security, I recommend to set stricter KPI’s for your managers and transform Security Officers into friendly but honest consultants.

Resource planning

Resource planning is an essential aspect to doing projects. You need to do this however for a large part outside de project context or outside the control of the project management office. It will need to be done by the (operational) IT managers. I thought to write this down as I see too often that organisations still struggle with this. Though it will never be a stroll in the prak.

Projects come and go and are generally resourced partly through people from the existing operational teams and partly through temporary hiring. Projects are these days less about completely building something new and more about adding or changing something that already exists. Therefore it is important to use existing skills and knowledge.

Certain resources will work almost fully dedicated for the project for a longer period of time. Other resources will need to perform tasks intermittently and for shorter durations. Planning the latter group is the most difficult. Those people will work probably for many projects and will also have to perform operational support tasks.

Because the IT manager will know which person has the right skills to perform the required project tasks, it is the IT manager who will need to do the resource assignment. In fact, the IT manager has the responsibility to maintain the full resource planning for everyone within his team. Additionally, it is advised that project resources are also recruited and managed by the IT manager. In that case, he can assign some support staff to work on the project so existing knowledge can be leveraged for the project and some of the temporary staff can do support work.

With respect to resource planning, the IT manager will first of all need to make an estimate of the total amount of operational support work he has that needs to be performed. These tasks can be work related to:

• Operational support tasks such as incident and problem management, fulfilling user requests, responding to system events, systems monitoring, service desk tasks, applying software patches, replacing faulty, etc.
• Proactive support tasks such as upgrading software to a new versions, structural hardware replacement or implementing changes as requested by the users (all these activities could potentially be executed as projects).
• Overhead tasks such as team meetings, training, holidays, sick days, etc.

This gives a baseline of the amount of resources that is minimally required. Certain tasks will require to be performed by people with specific skills. In those cases you will need to plan on an individual basis.

It is not always required to plan on the individual basis and you could maintain the information on the summary level.

The “ total available” gives insight in how much time is available for projects. If projects require more, you will need to insource additional people. If these resources work only for projects, then you could leave those people out of your operational resource planning and leave the management up the project manager or the project management office.

As you will perform multiple projects and will have multiple project managers, you will also have some project coordination through a project management office or something similar. 

When planning all your projects, you will need to ask yourself the question whether you will be able to perform all those projects. It happens unfortunately too often that certain resources are over-allocated by different projects because there was not overarching planning. Each project will have to make its own resource plan and the project management office will need to integrate those plans to see what the total project resource demand is per operational team or some cases per individual.

You will get a resource plan similar as you would have per team but instead of tasks you would haven projects. Each project manager will provide a single line item per resource or skill/team for the resource plan. You can then reorganise this demand to a demand per team. On a summary level, the total demand from all projects could be something like the table below.

If you then subtract the demand for a team from the availability, you see what is required for additional hiring of staff. Using the above examples, this is for team 1 as follows:

In this example, you will need an additional person with specific skills. Initially for 2 days per week, then for 1 day per week, then not at all and then you need this person again. That is unpractical. Usually you just can’t hire skilled people this way. Therefore you might need to adjust your project portfolio by either delaying or cancelling a project. Another option is to delay or cancel certain operational tasks.

Adjustments will need to be made continuously. You might need a Unix administrator only for 2 days at the end of the project. You will need to plan this into the resource planning but as we all know, projects run rarely according to the plan. You might even find out only a week before that you need to reschedule. Alignment between projects and the support tasks is needed. If you, as an IT manager, have been strict enough not to give away the time required for support tasks and have planned sufficient contingency into this, you will be flexible to accommodate these last minute changes. Instead of doing the support tasks next week, you do them this week. This flexibility can be obtained for a large part from the proactive tasks and less from tasks such as incident management.

What you definitely should not do is to ignore the issue and simply over-allocate the resources. What happens then is that support tasks are delayed or cancelled which over time will result in an increase in the number of incidents. What also will happen is that projects will take longer than planned and will be delivered with a lower quality. The latter will result in a higher number of incidents for the support teams to resolve.

Besides people, resource planning can also apply to the systems themselves. If you have 3 projects that all want to modify an existing component, all through the development, testing and production-deployment phases, you will need to align all these activities between the projects and support activities.