In IT security we are paid to worry about risk and stop it where we can. For this reason many IT Security groups have a reputation for being “the department of no” where projects go to die. I’ve been part of the department of no and teams would try to hide projects from us and the same teams would drop hints about what others were doing to keep us busy or sabotage other teams who were working on competing projects. This is not healthy for the organization nor the effort to improve security.
You might say “but they are idiots and want to …” “and that’s going to create all sorts of downstream security headaches.” To begin with, unless you are working in the world’s worst company that really does hire and retains idiots, in which case you may want to take a long look in the mirror, lets first off assume that the teams you work with have reasons for their actions. Secondly those reasons may very well be bad for security.
Your first goal when working with other teams is to get inserted into the process as early as possible. It will be much easier to re-design a poor project if you know about it before code has been written, contracts have been signed, or equipment has been procured. If you find that you consistently find out about projects right before, or worse yet after, deployment then step one should be to work on the culture to make sure you are included in new projects. To do this you can’t say no to everything. Put simply, partners are included; obstructions are avoided.
Once you find out about a project, whether it be in early planning or six months after deployment, your first goal should be to understand what the business owner is trying to accomplish. Once you understand this you can begin to try to understand the architectural choices. Once you understand the design it is time to begin the process of identifying risk. When risks are identified it is important that you go back to the business owner and explain the inherent risks and propose alternatives or failing that work with the business owner to identify more acceptable solutions.
Ideally, you should never go to a business owner with a newly identified problem and no suggestions for resolution or at least mitigation. That is a symptom of “no” thinking. If you can’t discover a mitigation yourself you should, at a minimum, take an approach of suggesting collaboration to find a solution. There are two reasons for this. One, it’s simply less combative and more likely to work. Secondly, left on their own, people who do not necessarily understand all the nuance of the issue you have identified may very well create a solution that meets the minimum requirements you have laid out only while making the overall architecture worse.
In security we far too frequently silo ourselves in out specialist cocoons and don’t communicate enough. I’m certainly guilty of this myself. But, we must exert effort every day to get out of this cocoon to understand the business and make sure we are building toward a better company. Saying no to every risk that comes along without offering constructive alternatives will assure that you are locked tight in your cocoon and everyone makes an effort to keep you there, ineffective and isolated.