Security Ripcord

Following up on any project is key.  Talking to all involved about what has happened, why it happened, how it could have better, what worked very well, etc is the key to improvement.  So, why aren’t organizations that experience a security related incident able to prevent or curtail future incidents?  Basically because they are not following up the incident with a lessons learned, or they are not doing it properly.

Incident Response should be handled like any other project.  It should be managed.  As most incident responders are aware, SANS GCIH course outlines 6 distinct phases of an incident response:

1. Preparation
2. Identification
3. Containment
4. Eradication
5. Recovery, and
6. Lessons Learned

Ah, Lessons Learned is the final step.  Actually, it is circular, so the final step leads into the first step.   I say leads into whereas a better metaphor might be “feeds.”  Or in the terms of following flow charts, for you management types out there, the outputs of Lessons Learned are the inputs of Preparation.  Here’s a question for you though, during your preparation phase did you look at the methodologies that you use to improve how you identify, prioritize, address, and follow-up on your lessons learned?  Or, when you are finished with your lessons learned meeting, do you have a list of action items that have been assigned to a specific individual who understands the criteria for successfully completing the action?

I just asked two questions that took your simple lessons learned meeting from a quick five minute session to a thirty minute plus session.  Although you might think that the issues will drive how long this meeting will last, in actuality that is not correct.  With proper methodology, in other words a practiced plan, this meeting can still be very quick while producing the key outputs that are necessary to augment your preparation phase.

Silver Bullet time.  Yes, I know, you want the silver bullet that is going to help you increase the effectiveness of your lessons learned process.  Guess what!!  Most likely you already have it.  Do you use process management to plan your software, hardware, or infrastructure development?  Bingo, then you have the means to improve your lessons learned.  Start using the processes that you already have in place.  I say this because it is the fastest and cheapest method to gaining control over this process.

For those of you who do not have a process in place, never fear, I have one word for you: Why.  Just ask why.  But ask it five times.  Asking why five times is the technique for determining root cause.  Gasp, Root Cause Analysis.  It is used during the Six Sigma process as well as being integrated into other project development schemes.  In his 5 Whys post Eric Ries explains that Taiichi Ohno of Toyota fame wrote about this technique in his book Toyota Production System: Beyond Large-Scale Production.

Now, this might seem silly to some at first.  It will seem especially silly to those individuals and groups that are not use to management their projects or doing root cause analysis.  This is where the longer meetings are going to come into play.  Of course, this is true of any new process.  New things take time to understand and get use to performing.  For some people the learning curve on how to conduct themselves in these meetings is going to be a long and tough journey.  But by consistently applying one of these methodologies to your lessons learned process you will find that each of your meetings is shorter and more productive.  The implementors will be happier because they are being heard (if they are participating) and the managers and executives will be happier because of the increased productivity and effectiveness of the end results.

Certainly I have only touched on this topic briefly.  If you have techniques that have worked to improve the effectiveness of your lessons learned meetings, please share them with us in the comments.

Go forth and do good things,

Don C. Weber

http://www.sans.org/?utm_source=web&utm_medium=text-ad&utm_content=affiliate_link1&utm_campaign=Cutaway_Security

Not all incident responses go according to plan.  This means that a responder has to have multiple methods for accomplishing tasks.  Harlan Carvey brings this up on his blog often and it is why Ed Skoudis created his famous WMIC Kung Fu write-up and turned it into a SANS Course: Windows Command-Line Kung Fu In-Depth for Info Sec Pros.

On a recent engagement this fact came into play.  I went on site knowing that I would have multiple types of Unix and Linux operating systems to potentially acquire.  From the customer’s description I also knew that I would be dealing with some older equipment but nothing from their descriptions seemed out of the ordinary.  Once I  got on site I reviewed the situation with the customer and everything seem normal.  As I was not worried about collecting volatile data from the system I requested the customer set up a maintenance window and temporarily take the systems off line in a manner that provided the least amount of impact to their operations.

All went well until the system administrator handed me the hard drive.  It all seemed fine at first until I tried to plug the drive into the adapter that was connected to my write-blocker.  The pins didn’t match up.  Although there were plenty of pins across, the layers were placed too close together.  It was fine for the blade server that it came out of, but none of my adapters could plug into this configuration.  At first I figured this was no big deal.  I decided to boot to a Linux boot disk and just copy the drive from there to a USB hard drive.  Well, there was two problems with that: 1. The blade server did not have a CD-ROM drive, and 2. the USB port was version 1.1 and would not recognize the external hard drive that I had purchased (no big deal because 12MB per second would not cut it either!!).  So, plan one == bust and plan two == bust.

So what was plan three?  Well, dump over NFS using native commands, of course.  Luckily the system administrator was well versed in NFS and the commands we were about to use.  So there was not a lot of explaining, I didn’t have to type commands, and my only real job (as it should be in this type of situation) was mindful and guided keystroke monitoring.  Here is what we did.

• To start off, please review this great guide on setting up NFS via the Ubuntu community wiki.  It does not dive deeply into NFS.  It just gives the basics on how to get it up and running on a live system or Live CD.  Of course, mileage may vary depending on distro, so beware.  Once it was all set up we navigated to the correct directories and prepared to acquire.  When all was done the system we were acquiring had a remote share mounted to /tmp/target.
• Before we started copying files we needed to keep track of everything we did.  Of course we could have done that as soon as we logged into the system, but as it was the system administrator performing the actions and this was not necessarily a “Live Acquisition” it was not completely necessary and we needed to have a good place, like an NFS mounted directory, to copy our files.  So we changed to the /tmp/target directory and ran the script command to record our actions and sent it to an appropriately titled file.
• Next we needed to record the system time.  Although we did note the BIOS time when the system was booting up, we need to record the time displayed by the operating system.  Running a quick date command proved enough.  No redirection was necessary as we were already recording everything into a file.
• We needed to know what type of system we were running our commands on.  A quick uname accomplished this.  Of course different distros also have different methods of providing version information about themselves.  Look to website for the distro you are working with to determine which file to check in and then cat that information so that it is displayed to the screen and thereby written to your script file.
• In order to get all of the system information written to the correct directory we needed several commands.  Unfortunately, if the system had been compromised and a rootkit had been deployed, there was the potential that critical information would not be copied.  To help alleviate some concern behind this issue we decided to run a few commands.  First we needed to know where each of our commands were located.  This was determined through a simple which command.  This let us know where the system thought the program was located and allowed us to call it directly as we did not want to rely on the $PATH environment variable.  Next we needed to get the versions for each command so that we knew which versions of the commands we were working with in case of any problems or other issues such as non-standard programs.  Most commands will take either a –version or -V and provide specific details about the command.  In this case we needed to know the version of md5sum, dd, and split that was provided by the system.  Once this information was displayed we had it recorded.  Next we took the md5sum of each of these commands just to be sure.  If necessary these outputs could be checked against known good versions from known good sources of the distro.  If really paranoid and the tools are available, other hashing tools could be used.  Although all of these tools could be “rooted” it is not very likely.  Plus, in this instance, we were not too worried about a rootkit, but you never know.
• Now were were ready to copy the information to our mounted directory.  The hard drive was recognized as hda by the operating system.  This means that we needed to copy /dev/hda using the dd command.  But since we were copying a large hard drive (80 GB +) we needed to use the split command to help with errors.  Now, I did not know this before we started, but I heard from one of my co-workers and it was confirmed by the system administrator, that copying large files (everything is a file in *nix) to a NFS mounted directory was not completely reliable.  To help control this I was told that copying to 2GB files would be the best way to handle it.  If something failed then it would be easier to pick up from the last good file and just calculate the proper offsets to start the copying process from  that point instead of the beginning.  Here is the command we ended up running: /bin/dd if=/dev/hda | /usr/bin/split -d -b 2000m - /tmp/target/server_name.dd. Although you can review the split man page to understand the full command, I will point out two things.  The dash “-” is necessary because it tells the command to use the STDIN from the pipe as the input file.  The “.” at the end of the command is also necessary because it is what split uses to number the files it creates.
• Depending on the system this will run for quite a while.  But before you run off for coffee and donuts or to analyze another system you’ll want to run one more command.  That command is the date command.  To do this just type date and press enter.  This will automatically run the date command once the previous command has completed running.  This time and date gets recorded into the script and the full run time is recorded for use in reporting and future efforts.

Although all of this took some effort to do, the end result was that I had acquired the system in a manner that I could use multiple tools to evaluate the information.  Once this was all complete I moved onto the second webserver where we had similar issues with acquiring the hard drive as the system was running on the same blade server.  I would love to tell you that I just followed my previous steps and that all went well.  Unfortunately I cannot.  We did perform all of the steps but as soon as we hit enter on the dd command the system virtually locked up.  This came as quite a surprise as the previous system did not take a significant performance hit during the acquisition.  We stopped the command and did quick review of the logs on this new system.  The log was full of I/O errors and we could only assume that the hard drive was slowly failing.  Therefore, plan three == fail.  That is where the system administrator came to my rescue.  As the system did not have any problem backing up every night we decided to just tar the operating system over to the NFS mounted directory.  Although this would not get everything off of the drive, it would at least get some of the information and some is better than none, at least at this point. Here how the tar was accomplished.

• Follow all of the previous steps to get the information about the system and the commands.
• Next you need to understand the version of tar provided by the distro you are working with.  Read the man page just to be sure you have the options determined correctly.  Because of the way that tar interacts with NFS (thank you, schism) it is probably going to be necessary to use the “–one-file-system” option.  This means that you will have to acquire each of your mounted directories separately.  For instance, if you have one partition mounted at /, one at /boot, and one at /home the “–one-file-system” command will not follow down the mounted directories.  You will have to do each separately.  The following command worked like a charm and then repeated for each mount point.  /bin/tar –one-file-system -cvf /tmp/target/server_name_root.tar /

So, after four tries I had all of the information that I needed to start my analysis.  Well, at least for these systems.  This simple acquisition really threw me for a loop initially.  Not only did I have to pull out multiple acquisition techniques it also affected my time on site.  That might not seem like much, but these extra step meant that I was on site for an additionally two days.  No small impact on the customer.  But, it could have been a lot worse.  If I had not been prepared with fall back alternatives, then I could have spent even more time on site.  Not only would this have impacted the customer’s pocket book but it would have also sewn the seeds of doubt into my capabilities.  This could have, in turn, jeopardized their view of the results of the analysis as well as the potential for the continuation of a forensic, or any other, business relationship.

Go forth and do good things,

Don C. Weber

Jeremiah Grossman has a simple but sweet post about what to do on your first day of work when you come on board to a company that has no “no existing web/software security program.” He simply asked, “What is the very first thing do on day 1? [sic]”

The meat of the post is in the comments. Although it started out with some typical guidance on how to technically identify server, applications, vulnerabilities, and the like, the comments quickly transition into focus on the people of the organization. Getting to know the executives, management peers, security and technical administrators, and even support personnel before diving in and trying to find problems and giving orders about how to fix them.

Security Professionals need to remember that there are other people out there. It has often been said that we need to refrain from saying “No,” “Don’t,” “Can’t,” and other negatively connotative words unless absolutely necessary. We often remind ourselves that we are a part of the business unit and that we are, typically, support personnel rather than the front line administrators (and if you are both then your security tasks should take the support model into consideration). So when it all boils down, we are saying that we have to be a helpful and viable part of the business by working with the other employees, no matter the level, rather than being the lonesome cowboy with six-guns drawn. Once we have accomplished this then we can start delving into identify critical physical assets, location of data, mission critical application, and other important technically-related security information. Hopefully, your initial dealings with fellow employees and managers will have already greased the skids to start working with this information, but it will have also provided you with a better understanding of the politics and business necessities surrounding the current state of technical deployment.

I’m not going to repeat my or anybody else’s comments here. Go check out Jeremiah’s post and then put in your two cents. But while you are there, notice some of the names of people who are commenting on getting to know the people and organization first before diving into the technical aspect of the position. You will probably notice many people that you know and respect.

Go forth and do good things,

Don C. Weber

I would like to start off by saying, “You can’t!!” The quicker you come to grips with that the better off you will be in the long run. Politics, or perhaps Micro-Politics since I am talking about intra/inter-office politics, is just a fact of life. Everybody has an agenda whether it is to further themselves, further their family, further the company, or any number of other things. So, get over it because it is just going to happen.

Now, let me tell you how you can control politics. I’m not talking “hand of God” control. I’m talking about making it difficult for politics to adversely (because some politics are good) influence the security of your organization. The answer can be found in my previous post on Organized Security. The answer is “Document Your Processes!” Okay, that is not the full answer, but it is the start. Getting your processes written down and accepted is the first step. The thing that seems to be working the best for my team is to document a process’ flow before writing down the procedure. Understanding the actions, decisions, and touch points of a process before writing the document that details each action and decision point. Here is a simple example pertaining to a user account request. This process flow utilizes “swim lanes” to show different teams or departments.

Once you have created this flowchart it is very hard to justify a deviation from this process. It becomes even more difficult once you detail each box in your procedural documentation. Getting your management and each team or department listed in the “swim lanes” to sign off on their involvement with the process will decrease the deviation possibilities even more. And if all else fails, it will make deviations readily apparent to management and all of the teams or departments involved.

Now, this does not mean that deviations will not happen. It is a fact of life that a situation or event was not taken into consideration during the development of the process. These instances shouldn’t matter in the grand scheme. Once the event has happened and been addressed, the individuals responsible for the process should quickly run through the process to see if any documentation needs to be generated or additional actions taken. After everything has been addressed the team can conduct a lessons learn to determine if the process needs to be updated or if the deviation was just an anomaly that will rarely occur and can be addressed on a case by case basis. Of course, politics can fall into this category. But all of this, as I mentioned, makes the deviation very apparent and the extra work associated with running back through the process and evaluating the overall process should raise questions about the validity of the action.

Once everything is documented and approved there is another very important step. That step is to consistently apply the process. Lack of consistency will leave gaps in all of your processes. Lack of consistency will breed contempt for your system and provide individuals and groups the leverage they need to circumvent the process in question and possibility the other processes developed by your team.

In the end you are not going to solve politics in your organization. You and your team need to learn how to accept it as a part of doing business. Just remember, diligent documentation, repeatable processes, and consistent application will protect you as much as they can.

Go forth and do good things,

Don C. Weber

Well, this week at work was very interesting. Actually, the last two weeks have been extremely busy. As Friday rolled in I looked into the eyes of my team members and I could see the tired, slightly overwhelmed, and, for some, haggled look in their eyes. They had shouldered what our organization decided to throw at them and they pulled through with their heads held high. No small feat when you are talking about a crew with that was built from individuals with very little security background and a manager (me) who is hell-bent on documenting and improving each procedure as they are going through it. I do this not only to help them build a program that is repeatable and lends itself to self-improvement, but so that our customer can “feel-the-pain” when their goals are not being accomplished due to the never ending “high priority” additional tasks (something I, and others, refer to as “firefighting”).

I usually make it a point to congratulate my team members for a job well done. It builds confidence, denotes achievement, and helps give a sense of closure to on-going tasks and issues that never seem to have an “end.” But this week I went a step further. I let them know that when they are working on the “high priority” issues, when the “firefighting” is taking all of their time and effort, that the things they are doing are enough. Just working the task is enough to help secure our environment. Even if they haven’t completed the task or specific issues mean they were not able to address regular duties and other tasks, as long as they worked hard and smart, it is enough.

It has to be enough. No environment is ever going to be 100 percent secure. Security professionals and security cynics can all agree to that statement. But, when you look at it from the other end, no environment is zero percent secure either. Each operating system comes with some controls. So every environment starts a little bit “in the black.” As an organization starts adding personnel and controls they increase their security percentage. Finally, with the addition of security professionals and a well-rounded security approach, an organization sees its greatest jump towards the unobtainable 100 percent secure goal. Just dong things to move towards that endpoint is enough. And I think that sometimes organizations and managers forget that aspect of the big picture.

So, when you get back in the office next week, take a look around. Look at the accomplishments of your team members. Take note of these accomplishments and provide the appropriate praise to the situation. Let them know that their efforts are enough and that because of their actions the overall environment is more secure. Then look at the other individuals in your organization. Look at the system administrators, the desktop support personnel, the help desk operators, and everybody else. Look at their actions and point out their accomplishments as well. Let them know that they are helping secure the environment and that their actions are enough.

If you do this, you are doing enough and you are speeding up your progress towards that unobtainable goal.

Go forth and do good things,

Don C. Weber

I’ve been doing a little running lately getting ready for the Corpus Christi Beach to Bay Relay. Today, instead of our usual four mile run, we decided to work on some sprints. We ran a mile and then started a series of 100 yard sprints with a 100 yard walk in between. Needless to say that the walking reset was filled full of huffing and puffing. At one point I noticed that I was hanging my head like most people do when they are tired. When I realized this I did what I always do, what I taught myself in the Marines after long runs and forced marches, I raised my head and started looking around. I use to do this because whenever you are the most tired is when you are the most vulnerable. You are not paying attention, you are breathing heavy, and you are doing everything you can just to take a break for a minute or two. Fortunately, the repercussions of me doing this now are not the same as they were back then.

All of this got me thinking about how we react to situations as a whole. I started thinking about how through training and effort we can begin to overcome hardships. I started thinking about how diligent practice can instill good habits and create muscle memory in any individual. Muscle memory is a condition where a body reacts without, or more precisely with only a little, thinking. You can see this by reviewing Rich Mogull’s posts on how he handled several car accidents after being out of the paramedics for a while. Rich did what came natural to him. He just reacted and, I’m sure, did a great job and a service.

“Yes, yes,” you are thinking to yourself right now. We have heard this all before. Practice makes perfect. Practice your incident response. Practice your backup procedures. Practice your disaster recovery. Practice makes perfect. Practice, Practice, Practice. Blah, blah, blah. Yes, I am tell you that. But what I want to emphasize is that you can train yourselves all day long and still make mistakes.

Running with my head down took me back to the days of running through the hills of Camp Pendleton and training myself to keep my head up and aware of my surroundings no matter how tired I was at the time. But what it really got me thinking about was being in the stack. Not the stack you are use to hearing about, the stack of Marines that are just about to enter a building or room that may contain hostiles. It didn’t matter where we were, once people started lining up and getting ready to move to action, their heads dropped. Not because they were tired or lazy, but because they were focused and waiting. Like a spring ready to uncoil all of its power. This occurred so often that it was not surprising to hear, “Keep your heads up in the stack!” whispered over the radio. Or have someone give you a quick rap on the helmet as a reminder. Everybody did it, everybody got sucked into it, and everybody was aware of it and watched out for their buddy, because that person was watching out for them.

So, how does this apply to us? Well, security professionals have a lot to accomplish on any given day. Logs to review, servers to patch, incidents to respond to, training to develop and give (and that is just the short list). Let’s face it. We are swamped with responsibility and duties. Everybody groans when we walk into a room but everybody notices when our duties start falling behind because it directly affects their business. With all of this activity, with all of this responsibility, it is very easy to get set into a common routine or mode. It is very easy for our heads to drop into our computers, logs, management consoles, spreadsheets, etc. We are doing our jobs and we are getting it done, but are we aware of our surroundings. Are we aware of the common sights and sounds of the office environment and server room. Are we listening to people talk when they need our guidance, input, or for us to listen for listening’s sake?

If you are, then good on you. Now look around and see who is not. Please, tap them on the head and tell them, “Keep your head up in the stack!”

Go forth and do good things,

Don C. Weber

Work has been quite an experience over the last couple of months. I have spent my time in the usual security professional mode - Firefighter. It is especially aggravating when much of that firefighting is documentation for certification and accreditation of a system (that could be quickly improved with the same level of effort) or collecting information through what could be considered broken processes. Security Blog readers hear about both of those concerns all of the time as they peruse the Security Blogscape. Security professionals wishing that they could make a difference within their organization. Wishing that the managers of the system and network administrators would just listen and implement. Hoping that the executive management will empower the security professionals within their organization by conveying to the rest of the company the importance of secure operations. Let’s face though, when we start talking about security within our different organizations the majority of what we want is for our organizations to follow good business practices. Companies who have a firm grasp on how their technology operates and have a process for change through open communications are much more secure that the companies that buy security products to act as stop gaps and try to prove or give the illusion of compliance.

The next generation of security professionals need to recognize this fact. Certainly we train them to know that their companies should be following industry standards like ISO 27001:2005 as I have already pointed out. But have we really started providing them with the abilities to integrate this into ITIL or CMMI. No, that is because for a business to achieve these standard they need to have business professionals to guide them through the process. Unfortunately, these business professionals have not been trained on how the security frameworks will fit into the organization and their compliance efforts. So, there is a gap. And when there is a gap that people don’t understand they tend to do one of two things:

• Ignore it.
• Throw money at it until they wish they had gone with the other method.

We’ll let me let all of you in on a little secret. It is something that you can take back to your organization and begin to implement immediately and it will not affect anybody outside of the security group, at first. Are you ready???? You might just hate this answer, so stop reading if you cannot handle it. Okay, I want you to “Document Your Processes!” *Gasps are heard around the world* Yes, documentation will get you over the hump. I’m not talking long, drawn out documentation that makes you stop everything that you are doing. No, I am talking about quickly documenting the steps you take to address any issue you devote time to repeatedly. I am also talking about creating process flow diagrams that show where and how tasks touch other departments within your organization. Don’t spend a lot of time on it at first. Just get it written down and saved into a location that all of your team members can access it. Then print them out and put them in a binder that will become your Standard Operating Procedures (dang, how did SOP slip in there?). As this binder starts to fill up, make copies and deliver a a copy to your boss and the other managers of the departments you deal with on a regular basis.

Now the ITIL and CMMI experts are ready to jump in here and tell us, “This is not enough to be compliant.” They would be correct. But each of them will have to admit that it is one way to start down the path. It is a necessary step that they will be looking for as they go down their checklists. See, a few of the things that they want to see from you and your department are:

• Does your department have documented processes and procedures?
• Does your department control their efforts through some type of program or project management method?
• Does your department have methods to analyze and improve the processes and procedures?
• Does your department make these process and procedures available to other departments within the organization?

By documenting how you approach each one of your department’s responsibilities you will start down a path that can be successfully integrated into the organization’s business processes. Managers will be able to start looking at your productivity and perform metrics on your duties which will help them determine many things, such as your value to the whole organization or whether your department is short handed. And what does it do for your department as a whole? You become more effective and efficient because you start doing things the same way every time (until it does not make sense to). You have opened communications to the rest of the organization and provided them with a method to take your example and some of your ideas and turn them into their own ideas (oh, the power of suggestion). All of this documentation you will help you and other members of your department quickly determine where your processes need improvement. Process documentation is an excellent tool when it comes time to point out issues to the members of your department. It drives straight to the heart of the problem in a manner that is easy for them to understand and provides them with the opportunity to make visible and fulfilling improvements.

Is all of this enough to “fill the gap” that I spoke of earlier? Of course not. It is just a start. One of the things that I am starting to consider are classes and certifications in program/process management. For this I have been pointed to the Program Management Institute by several security professionals and bloggers. I really don’t think it is going to hurt any security professional if they add PgMP, PMP, or CAPM to their alphabet soup. In fact, as individuals begin to progress through their careers these or similar education may become necessary. Many of our technical Brethern (who are still reading) are shifting uncomfortably in their seats because dreams of management duties are starting to fill their heads. Those, at least, that don’t come from a structured software or hardware development background. And they shouldn’t. Because these are the skill sets that are also necessary for technical engineers to improve how they do their business as much as it is a means for the managers to improve the department or organization.

Open communications is one of the things that we promote within our organizations. If your organization is “open communications challenged” then you must first start looking at yourself before you start pointing fingers or stomping feet. You must set the example. Live the lifestyle you preach. Hopefully it will make a difference. If it does not, well, then at least you have improved yourself and your department. The people around you will be more prepared for the next thing that comes along.

Go forth and do good things,

Don C. Weber

Apparently somebody over at the NBA’s Sacramento Kings franchise is upset that several of their cheerleaders were photographed partying. Now, first off, I don’t see that problem with this. These cheerleaders are adults. They are not necessarily responsible for being the role models like the NBA stars on the team. They are sex symbols. They have been hired to be sex symbols. And, if anybody does not like that term, fine….they are models. They have been hired to arrouse the attention of the largest demographic associated with the NBA, young and middle aged males. As models, and sex symbols, they are use to parading around in their underwear and being photographed. In fact, they like it. It is their job and it does not surprise me they can be found doing it during their off time. Really, the biggest thing they are guilty of is allowing a person to photograph them who was willing to place the photographs on the Internet. Maybe the Kings are mad that they did not get the royalties associated with the pictures.

All of that said, I guess it really boils down to the contract that these cheerleaders signed with the Sacramento Kings and, possibly, any policies that have been published by the NBA. Which leads me to consider any other jobs that these women may hold. Although most of them are probably models, I am sure that some of them have other jobs of varying responsibility. This leads me to the question of what if one of these women worked for you and she was one of your organization’s security professionals? What if she was your security analyst, team lead, or Chief Information Security Officer? Would these pictures have any bearing on her job status? Does this type of behavior demonstrate a lack of personal responsibility and open the flood gates to potentially compromising business situations?

My answer: I don’t know. I think I would have to weigh this situation with the personality of the individual, previous and current job performance, and any input by that individual while reviewing this information. Of course this all changes if there is a government issued security clearance involved. Which means that I would have to consider this information as possible behavior that could compromise the integrity of the individual and therefore increase the risk to national security.

Please leave a comment if you have an opinion about this topic. You can also read what other security professionals are saying about it in the Security Catalyst Community under the thread with the same title as this post.

Go forth and do good things,

Don C. Weber

Security Ripcord

/Hoff has inspired me again in his post Security Today == Shooting Arrows Through Sunroofs of Cars?. Actually, it was really more a combination of Tim Wilson’s post at Dark Reading and a quote from a show on the History channel that got me thinking. I’ll assume that you read Tim’s post and I’ll paraphrase the quote.

Darwin did not advocate that the strongest of a species will survive. Rather, he maintained that those species that adapt to change the fastest will survive.

I definitely agree with Tim’s posture that we need to evaluate how we are assigning priorities to issues identified in our risk assessments. I think it is definitely safe to say that most organizations are concentrating on the most visible protections and believing that they coincide with the greatest benefit. But, unfortunately, I am starting to think that many of us are not looking at the bigger picture. Yes, it is true that user activity, whether end-user or administrator, is the biggest threat to an environment. This may come from incidental activity, overt disobedience to policies, or even outright malicious activity. And it may be that awareness training is a big hitter when it comes to impacting security within an organization. But I don’t think it is the root cause and therefore the cost benefit is too low because it is not addressing the real issue.

Okay, just to clarify, I know that Tim was not trying to specifically come up with a ultimate solution outside of the fact that we need to think more outside of the box. And that is what I am trying to do here. In December of 2006 Time magazine writer Jeffrey Kluger published an article titled: How Americans Are Living Dangerously. In the article Jeffrey talks about how more Americans are killed in car crashes than in airplane crashes. Yet, despite the solid research findings, the majority of Americans prefer to drive than fly. This love of driving and be explained by Americans wanting to be in control. It doesn’t matter if the best person in the world is flying or driving. The majority of us want to be in the driver’s seat. In addition to control there is also the issue of personal choice. A person’s vehicle is their home away from home. I think a great example of this was shown in the 1992 film “Singles.” In the movie one of the main characters was involved in building a train system for the city of Seattle. After coming up with an elaborate and feasible plan he presented it to the major of the city. The major loved the idea but refused to fund it. He did so because he felt that the majority of the citizens of Seattle would not be willing to give up their personal vehicles and the train system would be a failure and a tax burden.

I say that we have this very same problem when it comes to computer systems. I don’t remember who said it but several months ago I heard somebody state that the biggest mistake in the computer industry was to name computers “Personal Computers” or PC. This gave the impression that a persons computer is their own property to do with what they will. Although this may be true at home, it should not be so in the work place. A much better term for business computers is “workstation” as it very clearly outlines the purpose of the system. Businesses should take these “workstations” and start planning how to limit the applications and services to only those that are absolutely necessary. Actually, I am starting to think that I prefer the idea of thin clients or Citrix deployments. Couple that with user awareness training and we are directly impacting one of the largest threat vectors.

Of course, how do we get the end-users and administrators past the warm, fuzzy, and cozy feeling of the “PC”? Well, I say that business should start treating their employees like adults. Most people in the information technology industry are smart and they should not be pampered. They need to have the expectations explained to them and then they need to be held accountable for those expectations. Organizations and employees all need to change to the threatening environment that they are computing within. Actually, in this instance, “need” is too strong of a word. Organizations and employees are not actually required to do anything at all. Change is not necessary to continue working in the short term. But those organizations and people who do change, the ones that look ahead and start planning their next steps by identifying root causes and being flexable, well, they will be the ones who are the most profitable and happy over the long haul.

Go forth and do good things,

Don C. Weber

Security Ripcord, Chris Hoff, Dark Reading, security evolution

I’ll have to say, moving from an organization that pushes back on change and external recommendations to one that embraces, analyzes, and implements recommendations and initiatives has certainly challenged me mentally. It is definitely time for me to “Put Up or Shut Up” when it comes to implementing a enterprise level security framework that integrates with the processes and procedures of the IT and development departments. Lucky for me the Department of Defense already recognizes the importance of information security and they have mandated many aspects of ISO 17799:2005. It is documenting the procedures and bringing them together so that each aspect augments the other that has proven an interesting, but so far not difficult, challenge.

For the last two months I have been working every minute at work. My blog reading has really suffered and it definitely makes me feel “out of the loop” on a lot of issues. Part of it is because by the time I get home I am done looking at a computer and ready to unwind. The most I usually bring myself to do is catch up on my emails to see if any of the other projects I am working on require attention. And even those projects have suffered a bit as you can see from my one month blog hiatus.

It is also a little difficult for me to break down what I want to write about. I have often started thinking about writing a post only to realize that after time a picture of security within my organization could be built by bits and pieces of my posts. The software we are using, steps we are taking, methods we have employed. Although initially seemingly innocuous could lead to “the death of a thousand cuts.” Another problem has been the fact that most of what I do is management. I provide leadership and guidance, get the ball rolling in certain directions, collect all of the information to try to find trends and determine cost, and act as the “face of security.” I even broke down last night and purchased a copy of Security Metrics which just reminded me that I have not been reading my feed list as I completely forgot about the SecurityMetrics blog.

All in all I just wanted to get something out there to let you all know that my one month blogging vacation is over. I am going to make a concerted effort to weed out the things I feel comfortable speaking about. This probably means that I’ll be moving away from some of my technical stuff and more towards developing and implementing processes and metrics. Such is my life.

Go forth and do good things,

Don C. Weber

security, metrics, process, Security Ripcord, Security Metrics, ISO 17799:2005