Thursday, 19 December 2013
Posted by Alex Ayers
10 characteristics of high performing security and GRC teams.
As we come to the end of 2013 I have been thinking of some of the projects that we have been working on in this time. One area of focus for me has been been working with clients to improving their governance around security and GRC. A key part of that work has been helping them define their target operating models, put in the right supporting organisational structures and get responsibilities and good decision making embedded in operations.
Much of this work is classical Organisational Design (OD) and there are numerous techniques and methods that can be used to assist with this.
Part of OD that is often difficult to articulate is how to really make a team effective.
Teams have to exist within wider organisational structures and what works for one organisation won't work for another. Budgetary, political (internal and external), & organisational factors provide constrains that have to be considered. Naturally our clients want to know what good looks like. Having accumulated a few hundred years of industry experience among the team has it's uses. We are very fortunate to have worked with some fantastic teams so we spent some time analysing common characteristics and behaviours that could be applied to any situation. These can be summarised as:
- Retain core competency. Overall accountabilityfor security/GRC/controls should not be outsourced. Without retained competency it is not possible to make effective decisions.
- Work with a partner with specialist skills to augment internal capability where required.
- Promote a nurturing and sharing environment. Everyone has skills and everyone can improve. 3rd parties and contractors often don't like to share and a good environment is one where that attitude is not acceptable.
- Invest in internal R&D. This a great way to develop skills of a team and generate innovative ideas and solutions to our challenges.
- Maintain strong business engagement. Our remit is enable the business to run in a secure and controlled manner. That is why we do this job and not being engaged with this audience means we cannot perform our job properly.
- Knowing limits. We frequently work with clients who have spent a lot of money trying to do things internally but have not invested in training or external support. Everyone has different limits but recognising them is important.
- Automate transactional activities. It is often cheaper to automate than to outsource and/or offshore. It also means that internal and 3rd party teams can focus on complex and/or value added activities.
- Operate strong governance over 3rd parties. Identify roles & responsibilities, embed standards, processes and procedures and operate contractual penalties for non compliance.
- Work with, not against suppliers. There are several common objectives which benefit all parties when they are achieved. Good governance puts in the framework to support this and manage under delivery by supplier or customer.
- Last but not least, Integrate with risk management and infosec functions. More often than not there is little to no engagement between SAP teams and risk management or infosec functions within an organisation. The years of SAP being a silo'd application that only moves to the beat of it's own drum are over.
I would love to hear any thoughts/observations/things that I have missed. Over to you.
Thursday, 12 July 2012
Posted by Alex Ayers
One of our clients recently remarked that our team offer something that their other partners in the security & GRC space don't - We keep them integrated with other relevant projects in their organisation and they are confident that they get the benefit of our experiences from other engagements and clients.
That is great to hear and reinforces my view that we take KT seriously but also got me thinking about how, like projects often are, security knowledge for SAP is still kept in silos.
SAP and the security ecosystem have done great work in getting the message out that as the technology platform improves integration and collaboration, there is the need for strong controls over the technology that supports this. Those controls are not the domain of just one team but from a security perspective we need to understand how they fit together to provide a secure environment.
There have been discussions on some of the SAP forums recently debating the role of the SAP security analyst (and the relevance of certification based on that role).
There are two prevalent views:
- Those who say that they retain a business focus and therefore roles are their domain and that's where they are staying. If SoD and SA checks are OK then things are secure (which will be the topic of another blog soon).
- Those who are developing their skills to meet the challenges of evolving technology and business practices. They view security holistically and while not necessarily being expert in comms, OS, DB, network security etc, they have an understanding of the integration points and dependencies between the components.
The business & technical components of security are not mutually exclusive and it is one of the things that makes this field such an interesting area to work. I do, however, believe that a credible security practitioner must be aiming to wear both hats if they want to be, and stay, effective.