Tap Dancing in a Minefield

or How to be an Effective Security Professional I am learning very quickly that an information security professional has to wear many hats and has to be a subject matter expert on a wide array of subjects. But ultimately no matter how much training and how many controls and policies are put into place the effectiveness of a security pro will be measured by the amount of buy- n the business has into security as a concept and how much security is on the minds of architects, developers, and administrators. If you don't have their cooperation you will find yourself chasing down and trying to correct fundamental problems that could have been prevented in the early stages of the life cycle. You will have have a group of very talented people trying to find ways around your controls and policies from within your enterprise. Definitely not a win-win. So how do security professionals deal with this issue? How do we get everyone on the same page to march toward a more secure enterprise? I find that there are times where the art of social engineering comes in quite handy when dealing with people within your own company. Depending on the ego, excuse me, person I am dealing with and my knowledge of the subject I will employ some of the following techiques in order to better secure applications and system from the ground up. Let's discuss what the options are... I use this one when people come to me early in the SDLC. I want to encourage this behavior so I will absolutely let the developers and architects help guide the security profile of their project. I actually enjoy this method the most as I learn the most from discussing why certain security features or functions may not be feasible but something I hadn't thought of could be used in its place. If you were going to get into this app, how would you do it? This is for the times when I am a shown a completed architecture but am little unfamiliar with the technology deployed or if I don't see any apparent weakness in the proposal. I dont use it that often but when I do architects and developers typically have fun with the question and come up with some pretty wild scenarios I would never lose sleep over. The Socratic Method (or Doing the Machiavelli) This technique is for the times when I am given an architecture or proposal that has holes that are pretty easy to see or if I know which direction I want to head in but don't want to issue edicts. I will start asking pointed questions to get the architects and developers thinking on a certain track, slowly (sometimes painfully) leading them to the design flaws or the inherent weaknesses. When I get them to see the issue, I will begin another line of questions that gets them towards the solution I think is best. Of course I will listen to them if they convince me that fears are unfounded or if there are mitigating controls I don't see or didn't know about. What do you want me to say? I took this one straight from the auditors playbook. Sometimes political pressures are put upon architects and developers to do things they know are wrong. So they come to me looking for my disapproval along with the rationaile they can take back to their superiors. Sometimes the security professionals role is that of official bad guy and who am I to disappoint? If we could tear this down and start over... This one is reserved for legacy systems that are being refreshed using the same design and architecture as the previous version. Whether the reason is technical constraints, political pressure, or intellectual laziness, I try to re-invent the wheel whenever possible so I use this method to get the creative juices of the developers and architects going. Sometimes the architecture get approved as-is with minimal changes but I have also seen complete redesigns after I have posed this question in a meeting. You will respect my authoritah! This is the nuclear option for security professionals. I have to use this one every so often but I have it at the ready at all times. If a project manager, developer, business unit manager, etc. are not willing to budge on their proposal despite my attempts to get them to make their system more secure I will dig my feet in, draw the proverbial line in the sand, and basically force someone above my head to override me. I guess in some ways it's a CYA manuever that shifts the blame if something goes wrong and my vocalized fears are realized. This is a very short list, and most of the time I use techniques that incorporate more than one of the above with others I haven't included. Securing a large enterprise is a difficult task that cannot be solved with technology alone. I am fairly confident I will write about this subject in the future, perhaps with some concrete examples of how I used one the techniques to make an insecure proposal into a (more) secure system.