I was reading the sample job description for Chief Information Security Officer and realized that not many of my organization’s clients has such a role defined. Clients due have a security team but the manager of this team is typically a director or vice president of technology.

Typically, these teams are focused on application or infrastructure level security as opposed to incorporating security in the strategy of the organization. These teams appear to be frustrated with the decisions management makes because they are given an application or technology and then told to make sure security policies are implemented. This poses many challenges if the security team doesn’t know the capabilities of the technology as well as the purpose of implementing it.

As a consultant in a smaller IT consultant firm, we typically don’t have conversations around future state architecture or organizational changes. If we were to be in those conversations, a chief information security office or at least someone in a strategic position with a security focus would be highly recommended. Ideally, my organization could offer a service in place of that position to create a new line of business.

I was working on an 8 month contract with a manufacturing company that specialized in paper products such as paper towels, feminine products, and other household items such as bottled water. At the start of the project, we knew that the security team created a culture of paranoia and needing to control all information and applications. At the kickoff meeting, my team was told that we will not have access to the production environment and if we do then we need to share our screen in a virtual meeting and of their employees will need to watch what we are doing. We were also told that the same rules will apply to their testing environment. For the development environment, the culture they created was at the forefront.

The security team had created a policy that any user information other than their network id was to be enforced in order to remain HIPAA compliant. We consistently explain what the HIPAA law was, what information is governed in the law, and how it does not apply to active directory information. Nevertheless, we had to cleanse all user data so that no personal identification was revealed in the development environment.

The security team also had created a policy that any asset information, related IT hardware, needed to be removed from the development environment. Ironically, one of our deliverables was configuration management and asset management which relies on this data to govern business logic in the application. As you can imagine, this made completing this deliverable almost impossible.

The security team also didn’t stop there. For their help desk tickets (Incident tickets), tickets related to root cause analysis (Problem tickets), and configuration of hardware changes (Change Request tickets), needed to have extreme business logic developed in order to align with their security practices. Any mentioning of a IT hardware’s network name, IP address, or port number needed to be removed from the ticket and added to a separate database for employees with the right access to look at. The challenge though is that the individuals assigned to those tickets also needed that information to do their job. Those individuals were most of contractors or external vendors. As a comprise, an approval process was put in place so that an employee of the organization can review the ticket, the data in the separate database, and who was assigned to the ticket. If everything was aligned with security’s policies, then they employee could approve the ticket to be worked and then the associated ticket would be completed.

Based on the security policies of the organization, we had to do a change request on the project that equaled almost double the amount of the original contract due to the length of time needed to overcome the challenges, take into account defects related to developing the deliverable without all the information, and the number of meetings needed to gather extra requirements. As a result, our change request was approved and we completed our deliverables.

A few weeks after our project was completed, we met with the customer to see how the adoption of the new applications was working out. We weren’t surprised that the customer said that their employees and contractors hated working in system and wanted to go back to their old system because the workarounds were much simpler. We kindly provided an explanation and offered to help change their system to make it right at a lower cost. Unfortunately, the security team disagreed with any changes and so nothing was done to assist with the adoption of the new system.

For some reason, the customer saw the lack of adoption as being the vendor’s fault aka my project team’s fault. Instead of putting blame on the security team for putting extreme policies in place, we became the scapegoat. As a result, we terminated our relationship with this customer. As of now, it appears that they are abandoning the new system we put in place and are going back to their old SharePoint processes which as you can imagine is wasteful spending in an organization.

The lesson I’ve learned from this project is there’s a fine line with security in creating policies. I do agree that the security team should create policies that protect an organization’s intellectual property and items that may cause a security breach. However, if there are enough controls in place to prevent a security breach and developers need the data in order to build controls and business logic to make the security team’s job easier then they should not be the road black in the development process. Also, if they do not have a clear understanding of rules and regulations and proper evidence is given to them that they are incorrect about their assumptions, then there needs to be a governing body that can overrule their policies and enforce them to change it. In the case of my client, this governing body was the owners of the manufacturing company. The organization chart of the customer was rather odd. The CIO reported to the CFO and the security lived outside of IT under the direction of ownership.