FFFFFFFound in the archive
I was cleaning up my hard drive when I found an unpublished blog post I had written in 2008 during my stint at American Airlines as an information security architect. The funny thing is that my views here have stood the test of time during my career as a security professional. If someone asked me to write on this topic in 2025 (17 years after I first wrote it), I don’t know if my current take would be much different. It would be way saltier and cynical, but otherwise unchanged.
Tap Dancing in a Minefield
or
How to be an Effective Security Professional
I am learning very quickly that an information security professional must wear many hats and 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 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 when 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 techniques in order to better secure applications and systems 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 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 don’t 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 rationale they can take back to their superiors. Sometimes, the security professional’s role is that of the 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 reinvent the wheel whenever possible, so I use this method to get the creative juices of the developers and architects going. Sometimes, the architecture gets 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 maneuver 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 of the techniques to make an insecure proposal into a (more) secure system.
2008 Dan at Work