Security Ripcord

My eight year old son has been asking to carry a knife. I have been wondering about knife safety and what it will take for me to let him carry a knife around.

When I think about it the knife has been a right of passage for little boys since the beginning of time. Banning pocket knives from school (as far as I know) is a very resent change to society. Banning them actually hurts our youth (in my opinion) because it deprives youth of learning opportunities that teach them responsibility and the consequences of action. Protecting people and kids from individuals that may decide to cut them with a knife is ludicrous because if they want to cut you they will bring a knife, permission or not.

Of course, I want my son to be safe. Therefore, I am going to set down some rules. This might not be the same method as our predecessors but when I think about it, my son is not going to be presented with the same “working” responsibilities as the youth or our predecessors.

My problem is that I do not have a good “knife learning skills” from my youth. Actually, I don’t even remember when I got my first pocket knife. I do, however, remember what was expected of me as a Marine. I was presented with very specific rules of weapon handling which were a requirement before I was permitted to enter a house with my platoon and a live weapon. These were the five rules of weapon handling I was responsible to know and demonstrate.

Rules of Weapon Handling

1. Treat every weapon as loaded, even after you have ensured that it is unloaded.
2. Never let your muzzle cover anything that you are not willing to destroy.
3. Keep your finger off the trigger and outside the trigger guard until you are up on target and ready to shoot.
4. Be sure of your target and consider the background.

Working off of these I have developed the rules of knife handling.

Rules of Knife Handling

1. Treat all knives as sharp even if you know that it is not sharp.
2. Never touch anything with your knife unless you want it to be cut.
3. Keep your knife folded or in its sheath until you are ready to use it for cutting.
4. Always cut away from yourself and other people.
5. When handing a knife to another person point the blade and tip away from yourself and do not let go until they say “Thank you.”

Rules are rules, but action is action. I can talk about rules all day, but unless you have trained to understand how to implement the rules there will be no learning. To help with his understanding of the rules I have decided to specify one of his plastic knives as an “actual knife.” He will demonstrate the following with the plastic knife first. Once I am satisfied he will move to a real knife and demonstrate everything again. I am hoping to show him that it is important to learn the rules and then that it is important to remember the rules.

Knife Tasks

1. Say, write, explain, and demonstrate all Knife Handling Rules.
2. Use a knife to sharpen a pencil.
3. Show how to sharpen a knife using a Spyderco Knife Sharpener.

Hopefully this works and provides the “real world” learning experience the youths of our past gained through actual implementation. Please let me know if you have any other tasks that might be helpful to learn these rules and promote knife handling skills.

Go forth and do good things,

Don C. Weber

When I started working for IBM’s Emergency Response Team I was a little intimidated about walking into a client’s environment and quickly providing incident response leadership. Luckily I was trained by Chris Pogue and Harlan Carvey to consider three things when I got on-site:

• What are you trying to answer?
• What data do you need to answer it?
• How do you get that data?

Obviously the first question is the hardest to answer (although, perhaps, not the most challenging). I often find myself having Car Talk-style conversations where you talk about the situation for an hour or two and then somebody says something to the effect of: “Oh, yeah. And we have this service running over here.”

It always amazes me how similar many of the security issues are across companies with decent security programs and teams. The security teams work hard to identify situations before they happen but incidents still occur and the teams struggle with pulling all of the information together. Disciplined incident response comes with experience. Not just experience within the security team, but experience throughout the organization. Most companies have information technology (IT) divisions with silo-ed experience (I am not saying it is bad, just natural). The web application developers and administrators know the web applications and web logs. Database administrators know the database logs, how verbose they are, how to retrieve them, and what can be turned on and off. Network administrators know what is logging where, what has been disabled, what can be turned up. Etc, Etc. Of course there is some overlap, but this example demonstrates that a lot of internal interaction may be required to initiate an incident response.

This silo-ing can complicate things but it is often manageable. The situations that prove to be more challenging are those that involve external services and equipment. Security teams are not usually consulted when service level agreements with external entities are formulated. Any third-party organization worth their salt will be prepared to provide information and action during critical times. But experience is the only way to determine the proper channels and methods of request to initiate the actions necessary to facilitate an efficient incident response. Acquiring data, removing services, increasing logging, and physically accessing a facility are just a few of the things that could increase the gap between incident identification and response.

Another thing that comes into play during an active incident response is the review of unique data types. I have assisted in several instances where an incident involved a web application running on an Apache server. The Apache web logs did not include any POST information which may have provided artifacts relating to the incident. As these web logs were the primary method for detecting anomalies the security team quickly realized that with the default configuration they may have been missing a few things. Digging a little deeper by including web application administrators and developers additional logs were identified. In a recent case the development team used Apache log4j to produce excellent activity information for debugging. As it did not introduce a performance hit to the server the developers just left the debugging code alone. The end result was a detailed log of the web server activity. The only real hick-up was that each entry was undocumented and multi-lined making it difficult to review by common automated processes. But, in the end, very helpful.

So, again, we come back around to the same incident response-related conclusion: Preparation is KEY. Understanding how things interact and who is involved is critical to reducing the time involved during each step of an incident response. But where to start with preparation? The results of an actual incident or a penetration test provide excellent examples and supporting data. Incident response scenarios are also very helpful but can be difficult to design and get everybody involved. To be honest, I have been a big advocate of “incident response scenarios” and I have told many people to develop them. But, looking back, I realize how hard it is for an organization to do this. Heck, it was hard for me when I was specifically thinking about and devoting time to developing a good incident response scenario. Therefore I am going to change my future recommendations from  developing incident response scenarios to performing system walk-throughs.

I made this decision when I found myself leaning back in a chair, looking at a white-boarded diagram of a system (by this I mean a group of resources combined for a specific purpose), and trying to determine what we needed to understand what might have happened during an incident. It was excellent because I also found myself and the security team asking questions to which we did not have immediate answers. I also found myself thinking about how I would have accomplished a specific set of actions relating to the incident. Coming up with these possibilities lead me to asking additional questions and identifying other resources-of-concern and data that could be used to identify useful network and system artifacts.

Therefore, my recommendation is that security teams periodically perform a system walk-through for various IT implementations in their organization. See how systems walk-throughs work and let us know your experiences. Pick one thing at a time when you start and see where it takes you. Focus on the things that will provide you information about a specific activity. Brain-storm situations and talk about the system and network-based artifacts that would be helpful. Folllow up on these ideas and pull in personnel to provide additional information when necessary. This will increase their experience and begin the collaboration process that may prove vitally important in future incidents. I also believe that these interactions will help identify risks, weaknesses, and vulnerabilities that can be easily addressed and increase the overall security of the organization.

Go forth and do good things,

Don C. Weber

Mentoring can be a powerful learning tool for learning specific topics. I have been thinking about mentoring a little bit because I have often found myself thinking that a mentor would be beneficial to my technological and managerial growth.  From my experiences I have determined there are a few requirements to setting up a good mentoring situation. Now, I am not a professional mentor, so, your mileage may vary.

• Focus: a broad range of mentoring subjects do not really work. A mentoring experience should be focused on a specific area.
• Time: both mentor and mentee must have time and inclination for the mentoring experience. Mentoring requires consistent meetings and reviews.
• Experience: A mentor must have knowledge of the subject and mentoring. A mentee must be able to learn the subject and be willing to branch out without encouragement.
• Desire: Both parties need to have a strong desire to participate from the beginning to the end of the mentoring experience.
• End State: both mentor and mentee must have an understanding of when the mentoring experience will end.  This may be after a specific set of goals is reached or a after a specific time period.

Personally, I don’t think that a blossoming Information Technology (IT) Security professional needs mentoring outside of the educational practices implemented by their place of employment. But that is the key: place of employment. Without a job it is difficult to implement the requirements that I listed above. Obviously this means that my list should include the additional requirement of: a job. Of course, a job is generally why a blossoming IT Security professional wants to enter into a mentoring experience.

How do people attempting to enter the IT Security profession get past this gap? My thoughts: effort, tenacity, and the will to teach. A well rounded IT Security professional starts by knowing a lot of things. They slowly, via experience, move to knowing a lot about a lot of things and eventually realize that they do not know and have not done everything. Once they realize they do not know everything they accept the fact that they will be learning during their whole career. I also believe that continuous effort and vocalism are requirements for becoming a well-rounded IT Security professional. Not only does this get you noticed by your peers, it expresses confidence to other administrators and managers.

As IT Security professionals mature they tend to filter into specific areas of focus. This usually means that the influential people in their lives become more narrow and they start to enter into good peer-mentoring relationships. By “peer-mentoring” I mean that each person grows from the other’s experiences. They drive each other to dig deeper and accomplish more. Eventually, people start developing other interests and the “peer-mentoring” relationships shift. But the excellent thing is that, generally, the previous relationships (business or friend) remain strong and continue throughout the years. At some point, interests will diverge again and collaboration will continue.

So, if you are just getting into IT Security or attempting to transition to a new focus area, do not get stifled or discouraged by the lack of mentoring opportunities. Rather, put yourself out there. Start working on personal projects. Tell people about your experiences, failures and success (because BOTH are important to the learning process). Do not be discouraged by critical feed back and have fun even if the subject is hard from start to finish. Remember, experience comes with time and effort. Learning the hard way helps people understand the easy and efficient way. In the end, people will notice and you will have achieved your goal.

Go forth and do good things,

Don C. Weber

I decided to follow up the *nux Live Acquisition Techniques post from a few days ago with a demonstration of image or file manipulation using DD and SPLIT.  This will help me get it all straight in my head while documenting it for prosterity, yours and mine.  Certainly there are other tools to do this, but knowing the basics is key to being good at anything.

Here is the scenario.

• Copy the swap partition using DD.  Get one big image and start manipulating it.  I could just copy swap every time, but as it continuously changes I will have a problem verifying some of the commands or techniques were successful.
• Get a hash of the image.
• Chop the image of the swap partition into smaller pieces using DD and the SPLIT.
• Pull the chunks back together using CAT.
• Verify that CAT successfully rebuild the image by checking the hash.
• Delete the last two chucks to simulate that the original copy, if it had been run using SPLIT, failed at some point for any reason.
• Chop the swap partition image again but this time skip the good chunks and only re-run the bad chunks.  This could end up saving A LOT of time in the imaging process.  Which, in turn, saves the customer money.
• Pull the new chunks together using CAT.
• Verify that the new chucks can be used to create a valid image by checking the hash.
• Stop SCRIPT, write post, grab beer (should have remembered to do this at the beginning).

In the following output I have added my notes while also bolding interesting pieces of output.  I did have a little glitch when trying to skip the good chunks, so be sure to watch for it and what I did to correct the problem.

user@cutsec:~$ script dd_stuff.txt <- Start SCRIPT so I don’t have to cut and paste
Script started, file is dd_stuff.txt
user@cutsec:~$ sudo -i <- Being root makes imaging swap easier. Plus, I like power!!
[sudo] password for user:
root@cutsec:~# cd /opt/Test
root@cutsec:/opt/Test ls
root@cutsec:/opt/Test dd if=/dev/sda5 of=./swap_orig.dd <- Copy an Image of the Swap Partition
2104452+0 records in
2104452+0 records out
1077479424 bytes (1.1 GB) copied, 96.2791 s, 11.2 MB/s
root@cutsec:/opt/Test ls -al
total 1053268
drwxr-xr-x 2 root root 4096 2008-10-01 22:19 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
root@cutsec:/opt/Test md5sum swap_orig.dd <- Hash it for verification
9a63cfbea3005551f4021aac7c287997 swap_orig.dd
root@cutsec:/opt/Test dd if=swap_orig.dd | split -d -b 200m – swap_split.dd. <- Split the Partition Image into small chunks
2104452+0 records in
2104452+0 records out
1077479424 bytes (1.1 GB) copied, 105.6389 s, 10.2 MB/s
root@cutsec:/opt/Test ls -al
total 2106548
drwxr-xr-x 2 root root 4096 2008-10-01 22:26 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.04
-rw-r–r– 1 root root 28903424 2008-10-01 22:26 swap_split.dd.05
root@cutsec:/opt/Test cat swap_split.dd.0* >>./swap_cat.dd <- Pull them back together using the CAT command
root@cutsec:/opt/Test ls -al
total 3159808
drwxr-xr-x 2 root root 4096 2008-10-01 22:28 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.04
-rw-r–r– 1 root root 28903424 2008-10-01 22:26 swap_split.dd.05
root@cutsec:/opt/Test md5sum swap_cat.dd <- Verify CAT worked properly
9a63cfbea3005551f4021aac7c287997 swap_cat.dd
root@cutsec:/opt/Test rm swap_split.dd.03 swap_split.dd.04 swap_split.dd.05 <- Remove chunks to simulate DD or SPLIT command failure
root@cutsec:/opt/Test ls -al
total 2721540
drwxr-xr-x 2 root root 4096 2008-10-01 22:33 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
root@cutsec:/opt/Test dd if=./swap_orig.dd bs=200MB skip=3 | split -d -b 200m – swap_new_split.dd. <- Start copying by Skipping first 3 chunks of 200MB
2+1 records in
2+1 records out
477479424 bytes (477 MB) copied, 38.3604 s, 12.4 MB/s
root@cutsec:/opt/Test ls -al
total 3188300
drwxr-xr-x 2 root root 4096 2008-10-01 22:37 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:36 swap_new_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:37 swap_new_split.dd.01
-rw-r–r– 1 root root 58049024 2008-10-01 22:37 swap_new_split.dd.02 <- Note the size
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
root@cutsec:/opt/Test mv swap_new_split.dd.00 swap_split.dd.03
root@cutsec:/opt/Test mv swap_new_split.dd.01 swap_split.dd.04
root@cutsec:/opt/Test mv swap_new_split.dd.02 swap_split.dd.05
root@cutsec:/opt/Test ls -al
total 3188300
drwxr-xr-x 2 root root 4096 2008-10-01 22:40 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 22:36 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 22:37 swap_split.dd.04
-rw-r–r– 1 root root 58049024 2008-10-01 22:37 swap_split.dd.05
root@cutsec:/opt/Test cat swap_split.dd.0* >>./swap_cat2.dd <- Pull new chunks together
root@cutsec:/opt/Test md5sum swap_orig.dd swap_cat.dd swap_cat2.dd <- Verify success
9a63cfbea3005551f4021aac7c287997 swap_orig.dd
9a63cfbea3005551f4021aac7c287997 swap_cat.dd
eec1975aed363dbd2254262594577da7 swap_cat2.dd <- FAIL!!
root@cutsec:/opt/Test rm swap_split.dd.03 swap_split.dd.04 swap_split.dd.05 <- Remove bad chunks
root@cutsec:/opt/Test ls -al
total 3803292
drwxr-xr-x 2 root root 4096 2008-10-01 23:02 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1106625024 2008-10-01 22:42 swap_cat2.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
root@cutsec:/opt/Test dd if=./swap_orig.dd bs=200M skip=3 | split -d -b 200m – swap_new_split.dd. <- Try Skip again but this time use the proper bs, MB = 1024*1024 but M = 1000*1000
2+1 records in
2+1 records out
448333824 bytes (448 MB) copied, 39.6093 s, 11.3 MB/s
root@cutsec:/opt/Test ls -al
total 4241560
drwxr-xr-x 2 root root 4096 2008-10-01 23:03 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1106625024 2008-10-01 22:42 swap_cat2.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_new_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_new_split.dd.01
-rw-r–r– 1 root root 28903424 2008-10-01 23:03 swap_new_split.dd.02 <- Note the size, that looks better
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
root@cutsec:/opt/Test mv swap_new_split.dd.00 swap_split.dd.03
root@cutsec:/opt/Test mv swap_new_split.dd.01 swap_split.dd.04
root@cutsec:/opt/Test mv swap_new_split.dd.02 swap_split.dd.05
root@cutsec:/opt/Test ls -al
total 4241560
drwxr-xr-x 2 root root 4096 2008-10-01 23:05 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1106625024 2008-10-01 22:42 swap_cat2.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_split.dd.04
-rw-r–r– 1 root root 28903424 2008-10-01 23:03 swap_split.dd.05
root@cutsec:/opt/Test rm swap_cat2.dd
root@cutsec:/opt/Test cat swap_split.dd.0* >>./swap_cat2.dd <- Pull new chunks together
root@cutsec:/opt/Test ls -al
total 4213068
drwxr-xr-x 2 root root 4096 2008-10-01 23:08 .
drwxr-xr-x 3 root root 4096 2008-10-01 11:46 ..
-rw-r–r– 1 root root 1077479424 2008-10-01 23:09 swap_cat2.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:30 swap_cat.dd
-rw-r–r– 1 root root 1077479424 2008-10-01 22:20 swap_orig.dd
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.00
-rw-r–r– 1 root root 209715200 2008-10-01 22:25 swap_split.dd.01
-rw-r–r– 1 root root 209715200 2008-10-01 22:26 swap_split.dd.02
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_split.dd.03
-rw-r–r– 1 root root 209715200 2008-10-01 23:03 swap_split.dd.04
-rw-r–r– 1 root root 28903424 2008-10-01 23:03 swap_split.dd.05
root@cutsec:/opt/Test md5sum swap_orig.dd swap_cat.dd swap_cat2.dd <- Verify success
9a63cfbea3005551f4021aac7c287997 swap_orig.dd
9a63cfbea3005551f4021aac7c287997 swap_cat.dd
9a63cfbea3005551f4021aac7c287997 swap_cat2.dd <- Success!!
root@cutsec:/opt/Test logout
user@cutsec:~$ exit
Script done, file is dd_stuff.txt

There you have it.  The basics of using system commands to image a partition, chop it up, and pull it all back together.  Hopefully this is useful in some capacity.

Go forth and do good things,

Don C. Weber

I hate the MS Windows command shell.  Maybe it is because I am not well versed in it or maybe it is just because I am lazy.  Not sure.  Either way, I wanted to find a nice way to create a list of all the files in a directory and put it into a file.  But, as I was working in Windows I didn’t want to open a command shell to get it done.  In steps Microsoft KB371379: How to add the Print Directory feature for folders in Windows XP and in Windows Vista.  This is a handy little feature that would send the directory listing directly to the default printer simply by right clicking on the folder and selecting “Print Directory Listing.”

Now, printing directly to the default printer might be fun for some, but it is not what I had in mind.  So, I modified the batch script a little.

@echo off
date /t > %2
time /t >> %2
echo. >> %2
dir %1 /b /-p /o:gn >> %2
exit

This adds a file to the specified directory.  This file includes a date/time stamp (accurate to a minute) and a plan file listing that does not include any other information.  I find this helpful for quickly including things in notes and reports and I hope that it helps you as well.

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

For the past week I have been re-involving myself in the Security Catalyst Community. While wading through some of the posts I had yet to read I came across one titled ICMP Tunneling by Donald Tabone. I decided to do some quick research and post a response. After reading it Andy Willingham suggested I post it here. So here it goes.

Donald’s question:

Hi All,

There has been an impending problem with MS ISA server that I have trouble defending against: ICMP tunneling which doesn’t seem to be stopped(firewalled). To my understanding it can be used for remote access and denial of service attack tools which use ICMP to establish covert communication channels.

Question is: What is the best approach to protect against something like what is described in the article quoted below using ISA Firewall.?
http://nulldigital.net/articles/stealinginternet.pdf

Thanks,
D.

My response:

Your best bet is to determine your ICMP requirements, determine how you can limit ICMP within your organization, create policies that specifically state what ICMP is permitted and not permitted, and then implement protection and detection in your countermeasures (routers, layer 3 switches, firewalls, and IDS/IPS).

Rational Security http://rationalsecurity.typepad.com/blog/2006/08/icmp_internet_c.html said people who do not limit ICMP “officially belong to the LBNaSOAC (Lazy Bastard Network and Security Operators and Administrators Consortium.)”. They then pointed to an article that briefly explains ICMP Attacks http://javvin.com/networksecurity/ICMPAttacks.html.

Your ISA should not be your first line of defense to the Internet. You should have countermeasure in place between the “wild” and this application firewall. Use those countermeasures to provide the protections the ISA firewall cannot and increase your defense in depth.

Go forth and do good things,
Cutaway

Policy is definitely the way to start. One thing I have thought of after posting this response is that I should have made it a little more clear about where ICMP should be in the policy. Although some organizations may have a specific ICMP policy, more than likely ICMP will be just one piece of the network or firewall policy. Certainly if you do not have any policies then you do not just want to start the time consuming process of whipping up a new policy before mitigating some of the risks involved with not locking down ICMP. Rather, come up with a solution (in this case for ICMP) and document how you have decided to handle it. Once you start working on your policies then you can use what you have documented as a starting point.

Go forth and do good things,
Cutaway

AndyITGuy, ICMP, ISA, SCC, Security Ripcord, ICMP Tunneling, ICMP Attacks, Rational Security, Donald Tabone, Malta Info Security

Okay, Windows NT has been out since 1993. Windows NT4 has been out since 1996. And to this date the developers at Microsoft have not provided administrators a way to automatically centralize their logs. Windows 2000 does not do it. Neither does XP, 2003, or Vista.

Why is this? As far as I know UNIX and LINUX have had this capability since their inception or at least near to it. But for now Windows administrators have to utilize third party applications to provide this capability and some people are reluctant to push them into production environments (See the thread on this subject, started by Anton Chuvakin, at the Security Catalyst Community).

Log monitoring is one of the key aspects of maintaining a working and secure environment. Centralizing logs allows administrators to quickly review events on their systems and networks while providing them with the ability to correlate those events with other log entries. Certainly there is always going to be robust alternatives that give the administrators extended capabilities. But I am amazed that Microsoft has yet to provide some type of simple, default, solution to administrators of their servers and workstations. I believe that it would go a long way to helping businesses and schools who cannot afford to purchase or implement third party solutions.

UPDATE: Thank you to Andrew Hay for pointing out some additional information on this via the thread in the Security Catalyst Community and on his blog.

The loganalysis mailing list had a rather lengthy thread on this topic: http://www.loganalysis.org/pipermail/loganalysis/2007-July/000254.html where Eric Fitzgerald from Microsoft explained the reasons for not having a native logging method.

Anton blogged about it here: http://chuvakin.blogspot.com/2007/07/why-there-is-no-syslog-in-windows.html
As did I: http://www.andrewhay.ca/archives/158

The thread was killed by the moderator before it got out of hand

Indeed, I should have Googled “why is there no windows syslog” as Anton’s blog post comes up first. Thanks again to Andrew and Anton. As I am writing this, however,, I see that both of these post happened on the same day as mine So, I don’t feel so bad. They just beat me to the punch.

And, of course, I appear to be mistaken about Vista not being able to forward events as it does have this feature through the Event Viewer Tool according to the reference Anton points us all to. This feature would permit you to consolidate your Windows logs. Unfortunately it is not currently compatible with Syslog. But why would they want to support a standard built for Unix, or rather BSD, anyway? Sure would have been nice of them if they had, though.

Go forth and do good things,
Cutaway

Security Ripcord, Windows NT, Windows NT4, Anton Chuvakin, Andrew Hay

One of the problems facing many universities is the use of their graduate students as developers and administrators within their departments. Although many students are very capable individuals they are often people who have limited or no experience in business environments. But, because the students are providing services for people who have limited experience with technology they are the duty expert. Now combine this situation with sensitive information. Are you scared yet?

Unfortunately it is hard to blame the people directly involved for this situation. The people utilizing the grad students do so because they have to. There is little money or the university wants to ensure that their students are given some real world experience. The grad students are just trying to expose themselves to as many experiences as possible before they move on to a higher paying job with benefits and vacation time.

Who is to blame then? Well, the people that permit this to happen, of course. There are several layers to look at when looking for responsible parties. You can blame the grad student’s professors for not closely monitoring the progress or accomplishments of their students. You can blame the grad student’s college for not instituting programs that utilize a software/system development life cycle with an detailed code review (after all this is what most people would experience at a programming company). You can blame the administrators responsible for the protection of the sensitive data for allowing access to the information. Or you can blame the administration for not having policies and guidelines in place to address all of these issues.

Really, the college environment is not usually built to facilitate any of these activities. Most universities have developed departments that operate in SILOs. Each separated from the others in duties as well as technology implementation. Often times these departments have learned to fend for themselves because of money and man-power. The man-power issue leads to overloading personnel with important duties, especially the capable and willing individuals.

One goal of an university security officer should be to pull the SILOs closer together. The more departments support each other the more information they can share. The closer each department works together the more likely they will be able to devote man-hours to ensure the grad students have proper monitoring and encouragement.

Go forth and do good things,
Cutaway

Security Ripcord