Monday, February 2, 2015

I've got a thought running through my head.  What if everything we do can be described as the difference between attrition warfare and maneuver warfare?

Attrition warfare is the tactical decision of the 19th century, and was codified by Carl von Clausewitz in On War.  von Clausewitz argued heavily for the kind of attacks seen during World War I, in which soldiers lined up and charged at each other.  These were heavily destructive battles that were exceptionally costly and ineffective.  This strategy persisted far into the Cold War and beyond.

It has mostly persisted due to simplicity.  It's a lot easier to teach Attrition War versus Maneuver War.  Now, jump back to the point at which von Clausewitz was writing On War.  He was a Prussian, writing about the battles of Napoleon.  Shortly after, the Prussian level of thinking also created the basis of the modern education system.   Prussia needed to move into the 20th century as fast as possible to prevent something like Napoleon from happening again.

Now, what the Prussians created was an attrition war versus the under-education of the the people.  In many aspects, that is still what the entire education system is based on.  But Attrition War has numerous problems.  It is costly in terms of human lives, and generally ineffective versus a decent defense.

Against the proper defense, attrition warfare costs thousands of lives.

Where does that all tie back towards Maneuver Warfare?  I think Boyd can answer that question.

Thursday, January 22, 2015

Corrective Action

I’ve been reading through Proverbs in my quest to finish the Bible this year.  So I’m using YouVersion and plan that has me read the entire thing in a year.  Technically, I started 2 years ago, and never finished.  But I picked up where I left off, and now I’ve been going steady since January 1. 

Anyways, I was thinking through the various parts about the correction of children.  I know correction has been simplified to “spare the rod, spoil the child”.  But that’s a hideous abbreviation of a collection of different proverbs.  Most of them say “don’t hesitate to discipline your child”.  But the comment is not often made on how to discipline. 

In other words, discipline should exist.  But I’m not going to tell you how to discipline.

If the Bible is the word of God, and God is smart, then what the Bible says should be smart.  I’ve got three kids.  The older kids (3 and 5) have completely different personalities.  Disciplining each child requires different actions and corrections.  Sometimes the reward is a positive reward, sometimes a negative reward.  But in the end, there is some sort of correction.

Throughout the parts of the Bible I’ve read, the correcting action changes.  God was not a one trick pony when it came to correcting the Jews, and as a parent we shouldn’t be either.  The old adage of “spare the rod, spoil the child” is the adage of a one trick pony. 

There is a second question that needs contemplated when talking about corrective actions.  Think back to the corrective actions your parents used.  And then answer the question: did it work?  I’m pretty sure most children will eventually parent the way their parents did.  They will use the same corrective actions.  I saw a lot of parents use corporal punishment.  I also saw a lot of kids who weren’t phased by corporal punishment.  Fifteen minutes after being paddled, they were back to their old ways.   In effect, the corrective action was not effective in solving the issue. 


The entire purpose of a corrective action is to get the person to correct their action.  It’s not for the parent to feel better.  It’s to correct the action that was wrong.  If the corrective action didn’t work, then new measures must be developed.

Wednesday, January 21, 2015

journaling

I was reading something from the Art of Manliness about Benjamin Franklin keeping a notebook in which he wrote down his successes and failures in his desired character traits.  I found an old military notebook that I used to have, and I think I want to do the same thing.  The notebook is one of those old green hard back notebooks filled with blank pages.  It’s kind of like your own personal hard back book. 

Mine is a bit old, but I still like it.  I always thought they were the greatest thing in the world when I saw NCOs carrying them around.  I don’t know why.  It was simply the mystique of an NCO and his book.  There was a degree of awe in seeing that book.  The books themselves were simple little things. 

Anyways, there is always the question of what should be put in the journal.  It’s not often you get a book that could last a few years.  Most of the time, you find some piece of junk spiral notebook that will last about 20 minutes.   And spiral notebooks never have the proper consistency or a solid cover.  Unless the attempt at solid is shoddy plastic.  Did I mention how much I hate spiral notebooks?

Anyways, I’m still contemplating what to write in the notebook.   I really like the idea of keeping track of progress.  Often, you find yourself committing the same mistake over and over again.  For some reason, we are blind-sided by our own faults.  We often see past them.  They just simply disappear.  


Tuesday, January 20, 2015

Network Baselines

Like I said, I’ve been working on network baseline analysis.  Beginning problem is that I don’t have a baseline to begin with, nor do I have any way to examine the current baseline of the network.  So, I’m at a loss of where to start. 

I read one book where a basic baseline can be created by pinging all available hosts.  It’s not the greatest baseline, but it is the beginning, and it’s better than nothing.  What I’ve got is nothing.  So what I did is wrote a batch file using a FOR loop to ping all devices and print the output to a file.  After that, I ran an arp –a and appended that to the end of the file. 

So it’s not the greatest baseline.  But it does give me an idea of what standard network performance should be, at least as far as PING goes.  I guess the next part is trying to dump the information into a webpage or a database so the information can be examined later and compared to what it has been at various points. 

I guess I should probably add the ITILv3 documentation to my reading list.  The only problem is I’m not definite the ITIL information actually provides information on how to baseline a network.  I understand the basics and the conceptual theory.  It’s a matter of going out and doing the work.  And sorry, SNMP is not the way to baseline.  Everyone has it turned off due to the insecurities in the system. 

Just a quick look at Cisco, and the only encrypted version they have only supports DES.  So the options are send the data as plaintext, or send it as an algorithm that has already been replaced due to inherent weakness.   15 years ago, DES was cracked in 22 hours.  15 years ago, I was happy with 400 MHz processor running 128 Mb of RAM. 

In comparison, I’m writing this on a laptop with an Intel Core i5 running at 2.5 GHz with 4 GB of RAM.  Shot in the dark, but I think a couple of these suckers could crack DES in a day.  And if someone breaches your network and doesn’t get caught, then what is a day?  What is 10 days? 


Monday, January 19, 2015

The end of one thing, the beginning of another.

I finished the Security+ book, and I think it left me with more questions than answers.  At the moment, I’m questioning how to do a lot of things.  Network baseline analysis is the primary one of those.  At the moment, I’m doing some preliminary reading.  Sure, there are a lot of books out there that say “this should be done”.  None of them discuss how to do network baseline analysis.  I think the best answer I’ve seen so far “there isn’t a standard”.  Which sounds pretty normal with network security.  And that’s why network security is, as a general rule, very splotchy.

With Security+ being finished, it’s off to learning physics VIA a collection of books written by Benjamin Crowell.  Part of me wants to write a long, drawn out blog post describing in detail how I can believe in both science and God at the same time.  But I’m not.  The answer is pretty simple: most of life is not an either/or selection.  Despite simplistic arguments against, it is entirely possible to believe in both at the same time.  The two are not mutually exclusive.  Sorry folks, I can believe in both at the same time.

I’ve touched on the false idea of mutual exclusivity before.   I can’t remember the post, but it’s the argument of people who want to lead you down paths that are only valid if the two items discussed in the beginning really are mutually exclusive.  For the most part, there are very few mutually exclusive items in the world.  I guess in the end, you have to question the assumptions people push at you, and assume everyone has an agenda.  Despite the best arguments, the truth is not the real agenda.

I think Andy Andrews put it best:  People often think logically to the wrong conclusions. 


Really, there was an entire book about that subject.  It was pretty interesting.  

Friday, January 16, 2015

Moving towards success

It usually feels weird, turning dreams into reality.  By and large, people are taught to dream big.  But they are never taught how to turn those dreams into reality.  Probably because it’s not fancy enough.  There’s nothing slick or amazing about it.  I guess people are in love with the fancy and great.  But it’s really simplistic stuff that causes success.

It’s strange, the amount of gain that can be had from just showing up and participating.  That’s half the effort in most cases, and that half is more important than any of the rest.  You could be the fastest, best person in the world but you aren’t going to get anywhere unless you show up and participate.  I’ll start with a good example.

It doesn’t matter how much you want to lose weight or “get in shape”, unless you do the work you will not achieve your dreams.  A person putting in 20 minutes a day will go farther than a person that shows up when it’s fashionable.  Sure, fashionable is a good time to show up.  But you must keep showing up.  Unless you keep showing up, you will never make it where you want to go.  And it’s really pretty simple. 

Show up.  Perform.  Rinse. Lather. Repeat.

I don’t care how much you want to know or learn.  Until you show up and perform, you won’t go anywhere.  Sorry.  It’s just not going to happen. 

Once you’ve made it beyond the “show up” portion, it’s time to spend a bit of time on the effort itself.  My other piece of advice is thus: don’t try to find shortcuts when you are trying to establish the routine.  Just keep showing up and chugging along.


Wait until the routine is established before you look for refinement.  

Thursday, January 15, 2015

Plumbers and Janitors

After a long trip around the Panhandle, I’m back at home.  I think I drove 250 miles today in my trek to get things ready for PCI 2.0 compliance.  It ended up being about a 10 hour day, but I enjoyed it.  It’s not every day you get to see good actions and results.  Maybe more on that later.

I find a lot of people in my industry don’t really spend the time or effort to achieve much.  Whether it be a chain or a person, they all seem to be drawn to mediocrity.  Either that, or I just don’t know what motivates them.  It’s very likely they don’t know what motivates themselves, either.  Just a lot of slouching towards the weekend with no real goal in sight, and no plan. 

I think I read in one book or another that the average IT person is best equated to a janitor or a plumber.  Both experience the same problem.  It’s in how they deal with the problem that makes their job descriptions different.  The problem in question for a janitor and a plumber is a leak.  A janitor spends most of their time mopping up the same leak.  They deal with the same problem over and over again.  A plumber finds the source of the leak, and stops the leak. 

With that idea in mind, I set out to be a plumber.  In order to be a plumber in the IT world, you have to know a lot and you have to begin to understand root causes.  If you are app’ing 5 Ruby II’s a month (not to be confused with a Ruby 2) due to lost program on a reboot, then you need to figure out how to solve the problem.   The solution is app the Ruby.  The problem is not the random power fluctuation.  The problem is the Ruby doesn’t hold on to its programming.  So the answer is replace every single Ruby battery pack.  Guess what?  You then forget how to app Rubys because they retain memory through a reboot.