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.
