In today’s world, there are many signs that employees, both inside and outside a given security program, are frustrated with its performance. I have frequently been called in to help security organizations reestablish credibility and enthusiasm. There are many reasons why these teams fail. I’m hoping that I can highlight some of the common disconnects and problems that can be easily fixed, that will help make a security program relevant and valued within its organization.
The IT security program has what appears to be on the surface the very simple fundamental reason for existence: protect the business, stop the bad people, and keep out of the way of doing business. This seems simple on the surface, doesn’t it? The CEO, the CFO, and the business units want this. IT audit expects this and the IT service delivery groups need this. The business partners, customers, and the public all expect this. So, why is there so much disconnect and angst?
The problem is that, for a security program to be effective, it has to be integrated. It cannot be something that sits alone as an outside organization. By its very nature, a security team is intrusive; it needs to have visibility, and needs to be aware of changes and problems. Most people don’t realize this, resisting what they regard as intrusion on their turf. Likewise, they may be reluctant to trust the IT security team with secrets.
So, the challenge for the CISO is that they have to position themselves and their team in a manner that doesn’t feel intrusive. How do you do that? The most successful approach I have found is to re-frame the delivery style of the security team as a service or support group for everybody else. We change the way we talk, present, and communicate in a manner that shows that the team can be relied upon to help. We have to position the security team so that is not regarded in the same manner as an IT audit department (a valuable ally in difficult political situations). The security team should take ownership of problems and not simply throw them over the wall, which leads to resentment and confusion over what is expected of the IT team.
To highlight the transition to this user-friendly model, I initiate the following activities:
- I create new documents that define the capabilities and roles of the security program as a series of services that show the commitment of the team and SLAs.
- I changed the mentality of all of the security teams to be more service oriented. I got them to regard their jobs as something meant to not only find problems, but also to help fix them. This is very important when dealing with IT service delivery teams. Their job is to ensure that systems continue to operate, no matter what happens. They want our time and zero interruption of service. They don’t want to find problems; they simply want consistent delivery. The security team is the complete opposite, in that they are focused on finding problems, highlighting issues that might require an interruption of service, or changing the way that the perfectly capable service has operated for years. A very diplomatic approach is required when addressing these issues. It is important that the two teams do not become alienated, adversely impacting their relationship and communications.
- I establish regular meetings where the security team meets with the other groups, both formally, and informally. In the formal meetings, we explain what the security team does and we listen, learning how others deliver their services inside the organization. The informal meetings should be designed so that we learn the personalities of the people we’re dealing with. In those moments of crisis we need to understand each others’ motivations, and can handle the stress better.
- I establish monthly and quarterly briefings that discuss the security issues, highlight our joint wins, and talk about our projects and special initiatives.
- As the CISO, I would wander the floors, making connections and talking with people outside the security organization. I would visit data centers and meet with the engineers, letting them know that I’m there to help and to answer any questions. I would make sure that my teams worked with the architects and the solution designers to resolve audit findings and find mitigations. This provided both security protection and the functionality required to achieve results.
- I would communicate our performance metrics in terms that were relevant to the business. I would also show how our performance compared with others, recognizing our successes, and admitting our weaknesses.
By doing this, I changed the perception of the security program, so that outside teams could understand how we worked and how our goals aligned with theirs, granting clarity into the inner workings of the security program.
This is a simple formula that has proven itself. I hope it helps you deliver success with your security teams.