Evolution of a Security Engineer

Everyone has a story.  For me it started in 2003.  I had been recalled to Active Duty from the Naval Reserve as a Unix Administrator.  I knew nothing of IT or Unix back then, but I did hold the qualities that employers look for - fast learner, on time, driven, etc. 

The short version of my story follows. My orders were up and I would have been going back to working four jobs - bagging groceries, naval reserve weekends, band gigs, and college.  The Air Force Technical Sergeant that I worked for knew I was worthy of much more.  He had a cigarette with another guy on one of my last days.  This man was looking for entry level IT Security people to become intrusion analysts.  I met with him and he asked me what I knew about TCP/IP.  I told him I could spell it, and he told me to go to Barnes and Noble, buy two books about TCP/IP so he knew I was sincere about the position, and I would be hired.  I did obviously.  I put myself on twelve hour nights purposely for the first year and a half so I could read, use the lab, and catch up to the required skillset and the rest is history.  It was pretty much a lucky break, and along the way I've been extremely lucky to have worked with some great mentors and people that have helped me grow quickly, coupled with jobs that make for an outstanding resume, and of course...a little hard work. I've had the luxury of growing up in security, and as such have worked the gamut over the past 11 years.  But enough about me.  What about everyone else? 
I would venture to say that most security administrators are prior server admins.  Most have probably come through the traditional IT ranks - helpdesk to client support, client support to server support, small environments to large enterprises.  Why?  Because our field is still young.  Most are converts from networking, server administration, or were administrators of security tools. 

Either way you came up, we all have new hurdles to overcome!

The Importance of Policy - Overcoming Personalities in a Flat Organization

On 2/9/14 I posted "The Importance of Policy" and promised at the end that I would follow up with some ideas on enforcing policy within a flat organization. To recap, the original question was basically this - If you are reviewing someone's project and find that they are not following policy, inform them of the offense, and they refuse to comply what do you do? Let's start with tackling this domestically. The first thing to look at is Maslow's Hierarchy of Needs; physiological needs, safety needs, love and belonging, esteem, and self-actualization. In it Abraham Maslow describes people as needing to be accepted and respected. How this occurs in a business environment is bureaucratic. In other words, the most important acceptance for the individual comes from his or her management chain. Maslow also describes a need for safety which encompasses work. In other words, nobody wants to lose their job and as such should be willing to comply if approached in the correct manner. Esteem and Self-Actualization are also key parts in Maslow's hierarchy which could be related. Encountering someone with low self-esteem may give the person making an argument the upper hand, if in fact the arguer has a higher self-esteem. Self-Actualization encompasses understanding the situation, making decisions, being moral and ethical, problem solving, and objectivity. This is an example of someone reaching their full potential. Maslow's biggest criticism is not being worldly. It is heavily weighted in domestic research. So what do we do in a global situation? The answer is simple. Look toward a global model, Max Neef's Fundamental Human Needs. The same ideas as listed above apply, although they are classified differently in this model and are not considered a hierarchy. The biggest difference for application here is how those needs are satisfied. Being able to answer this question for each need makes this model cross-cultural. Juan Antonio Perez Lopez' "Organizational theory: A cybernetical approach" may have some answers for motivations and interactions.

Phone Scamming: Alive and Well

I've heard reports recently of specific social groups being targeted for scamming.  I hadn't paid much attention to it really until recently.  I was targeted as was my Grandmother and Uncle.


I have a friend and colleague that recently took a trip to the islands.  Upon his return I received a phone call from that island.  I don't recall if it was the very next day or not, but it was definitely within a week.  Whomever or whatever targeted me had coincidence on their side for sure.  I did not return the call before asking him if he had given my number to the person he had left behind.  When he said he did not, I knew to ignore the call.  There was no reason anyone from Aruba, Grenada, or any other island should be calling me.  Turns out that shortly thereafter I got wind of this scam.

Building Security In

Let's take a second to talk about development.  For most of us there will become a point in our careers that we will have to work on some type of development project.  For some development may be a career, while for others it is just part of the journey of professional growth.  The model by which you develop may be different in each position you hold - waterfall, spiral, extreme programming, agile, and any other rad types that didn't make the cut for this post.


Security in development models has only truly become a concern recently; probably about the past 10 years or so with a major emphasis in secure coding for probably the past 3-5 years.  I'm not necessarily saying that security was never there, certainly early developers had it in mind or operating systems wouldn't follow the model of separation shown between applications, high-level drivers, low-level drivers, supervisory layer, and the kernel; dacl's and rbac wouldn't exist, and so on.  My only real point here is that it is only recently that security early in development has become a focus instead of an after-thought, and after so many people have been developing for so long without it as a major concern. 


So it should come as no surprise then that convincing developers to build security in is a tough feat to accomplish. 

The Importance of Policy

The very first blog entry starts with policy, because...well, everything starts with policy really.

I once interviewed for a job a ways back; a real career move into one of those important positions.  I didn't get it, but things were going as they should, when I get a fairly standard question.

To paraphrase:

"Let's say you are evaluating a new program.  You have identified several policy violations during your review (I noted they were careful not to say audit).  When you approach the project manager he says that he will not address whatever controls you found were lacking.  How do you get him to do it?"