Perceptions of Security

As mentioned in the previous section, security professionals must deal with stakeholders to gather the information needed to generate security reports. This effort is often hampered by the perception that many stakeholders have of information security teams. Many stakeholders are afraid to engage the security teams. One participant with over a decade of experience in information security described how many stakeholders he has encountered over the years feel about security stating:

The main issue that I’ve seen over and over and over again in companies is that IT is trying to move at 60 mph, [striving] to meet the demands of the business, and [then] security comes along. I don’t know that security necessarily says, [you] need to be going at 45 mph, but I think that that’s the perception that IT gets from security, [suggesting the] need to slow down in what you’re doing, making sure you’re thinking through it, but that doesn’t necessarily lead to the best practices.

This perception of security engenders many of the issues that security professionals experience, which affect the security report when working with stakeholders.

Another participant new to his career described working with a high-level manager who would bypass the security teams altogether because her experience was that security was going to prevent her from doing what she felt was necessary. As soon as an issue was sent for review by

the security team, she would escalate the issue to the executive team in an attempt to remove the security teams from the decision process.

A participant who now owns his own security consulting business explained that this perception of security is due to the security teams and the IT department all reporting to the chief information officer (CIO). As he explained,

The outcomes and the objectives, what they’re measured on, are vastly different. So, IT gets beaten up by the business to deliver solutions in enablement as quickly as possible, whereas security is sometimes perceived as a roadblock to both of those [efforts].

Two teams that closely work together are the application development teams and the application security teams. The application security team is responsible for scanning the applications for security vulnerabilities prior to the usage of the application in a production environment. This aspect causes the development team’s general dislike for the security team. In describing this rivalry, an experienced participant noted that the application development team felt that the application security team was similar to “somebody who passes on numerous commands and [acts in an]…extremely authoritative manner, [which] somewhat also creates a gap between the app teams and the security teams.” The participants concurred that this rivalry has led to many instances in which the application teams would delay the submission of information to the security team to prevent the latter from reporting issues, or constantly insist that the security team was wrong and continuously demand that the security team proves its findings in an attempt to wear down the team.

Most of the experiences that the participants provided were related to internal stakeholders or departments and their perceptions of the security teams. One experienced participant expressed his perspective on security teams:

As [an external] consultant, [I notice that] you are insulated from the internal politics and the internal battles that occur. You could see [the situation] happening. The writing was on the wall, but I would say most of the time you’re out of the room when those kinds of conversations happen.

Although external security professionals are not as directly affected as the internal teams, they are also influenced by the perceptions of the security teams.

In addition to this perception, external security professionals had to deal with the client’s certain level of mistrust. An experienced participant described her experience with this distrust as follows:

[The clients] already have some perception that they’re not sure whether the work is quality work or not, or…who exactly has worked on it. They do not know much about the person, So, I think the doubts kind of… build…and [this mindset] reflects [in their behavior].

With regard to offshore security teams, the perceptions are even more pronounced. The same participant, who had several years of experience in an offshore security team, recalled one such instance:

Clients expect that the consultant does everything because they are paying us for the work. So, we are answerable for everything. In that case, we are doing the assessment and helping them to build out a

program…everything is expected. [However,] it’s not possible to get everything done within 40 hours a week.

This perception that members of the security team are responsible for everything because they are being paid to perform a job results in a huge demand on the offshore consultants assigned to the client. As previously mentioned, when the scope of the engagement does not allow sufficient time for completion within 40 hours, the ensuing reports become inaccurate; unless the security professional works off the clock to meet the demands, many issues do not get reported.

Not every experience that the participants described was a negative one. A participant cited an instance in which an internal department head asked the security team to alter a security report to make it appear as a higher risk than the security team was reporting it. As the department head perceived the security team as being capable of advancing his initiatives, he used the altered report to gain a budget that he felt was needed to move the initiative forward.