February 12, 2014
Baaad blogger. No...wait, not bad blogger, but now infrequent blogger here. I can't have that long of a break and just let it go without mentioning something about the large time gaps. So here's the update:
I've decided to no longer update the "Reading Stats" part of this blog. I think by now you get the idea - and now that I'm reading more security books... well, it's not as useful to put my cards on the table. In addition, my studies have morphed into more videos, web seminars and in-person classes - along with a lot of online reading. The reading stats are not really covering all that I'm doing.
After my first attempt at the CCIE R/S Lab - I had started working towards a second attempt. Then I took some time to study for and attain the CISSP certification. It's something that I've wanted for a very long time. And then I started practicing for the Lab again. Meanwhile, the clock was ticking. I had to make a decision - especially when I received emails reminding me that 9 Cisco certifications were about to expire. So I studied for the CCIE R/S Written Exam - and passed it (again). This nicely reset the clock for the Lab and renewed all 9 certifications. Whew.
Of course, I took advantage of this breathing space by... taking an online workshop series for the C|EH! And now that I've completed that and while I was waiting for the EC Council to approve my application for the exam... I decided to study for the Wireshark certification. Yeah. I have wanted that certification ever since they created it. And today I took that test and PASSED! So now I am a Wireshark Certified Network Analyst.
Naturally, I'm simplifying the process. The actual process started years ago (2007) when I convinced my supervisor to get the 4 Wireshark Training CDs. I went through them from start to finish. And they helped me to go from muddling my way through a trace file to actually knowing what I was doing. And then I kept going. Every time the opportunity arose to perform and analyze a trace, I was front and center, waving my hands and shouting "pick meeeeeeee" like Donkey from the movie Shrek. For me, surfing the web is not shoe shopping; it's finding training videos - and there are plenty on Wireshark, Pilot, ACE Analyst, Observer, and other bit spitting. During this time, the certification was created. Then it disappeared. Then it reappeared and was turned into a certification program (now with continuing education requirements and study guides). I bought the Study Guide ... and then I bought the Exam Prep Guide. So when I saw the opportunity to study up and test - it was only a few weeks of prep, but it was also a few years of creating the foundation for that prep. And now I have another cert that I have wanted for a long time.
That leaves the C|EH and then back to the rack to finish the Lab. Yes, I know - if I don't retake the 4.0 Lab before the beginning of June, I will have to take the new 5.0 version of the lab. Oh...yeah... in the new 5.0 version they now have a new Diagnostic module (which is the meat and potatoes of the Operations crew) and Interpret Packet Captures! So am I studying for the Lab or am I taking detours?
On the one hand, it would be better to take the 4.0 Lab. I have already attempted it once and I pretty much know what's expected of me for that version. Although, the new 5.0 Lab seems to dovetail nicely with my strengths and may be somewhat more fun. Perhaps the answer will be in the next update.
Posted by BlueWolf on February 12, 2014
February 28, 2013
Happy Not So New Year
Wow. Has it been that long? I was very surprised to see that this is my first post of the year. I guess it is both good and not so good. Good - because I'm studying instead of blogging about studying. Not so good - because I had hoped to be further along and talking about it more.
The thing that prompted me to post is that I completed another book and had to add it to the list. I came home from work today and I read this book in one evening. The book is: "Your CCIE Lab Success Strategy - The Non-Technical Guide Book" by Dean Bahizad and Vivek Tiwari. Both are double CCIEs.
I had mixed feelings about the book. I expected a larger book. Perhaps something like the size of an O'Reilly topic was what I had envisioned. But it's more the size of a small guide book - or a Kindle. I opened it up and saw that the entire book was double spaced. Gasp! But as I read through the book, I found it to be a really good read.
There really isn't anything "new" in the book. Just about all the information or hints are things that are covered in the INE videos. There are no shortcuts. You have to be dedicated and persevere. Yadda yadda...yeah, I know. And that's okay. It's always good to hear it - and to hear it again.
The good part of the book is that it is ENCOURAGING. Even though it's stuff you've heard before, read it. As I was reading, I considered passing it on when I finished. At the end of the book, I decided to keep it - until I get my second CCIE. And that's what the real value of the book turned out to be (for me). I am going to read the book again whenever I get discouraged. I'm going to read it when I start getting sluggish. It's a really good pep talk when you need it.
The biggest recommendation in the book is the hardest to implement. It recommends a study partner. Finding the right study partner is really difficult in some locations. And finding a bad study partner is worse. So I'm going to take that recommendation with a grain of salt. I wish I didn't have to skip that part - a study partner would be helpful.
The part that I found encouraging is the undertone that it is -normal- to want, work toward, and attain TWO CCIE certifications. And it was uplifting to hear that the second one is easier than the first. You already have a strong foundation (your first CCIE), you already have a study method, and you have already proven to yourself and others that you have the drive and persistence needed to complete such a daunting task. All that's left is the doing.
I also got another book this week that I'm poking my way through -> Guide to TCP/IP Fourth Edition by Jefferey Carrell, Laura Chappell, Ed Tittel with James Pyles. OMG I am so excited about this one! Jefferey Carrell was the instructor at a Riverbed workshop I recently attended. It was a great workshop on Pilot and Wireshark. This is the TCP/IP book that I have always wanted. It doesn't just go through some dry rehash of protocols. This one is more of a hands-on guidebook - complete with trace files. Yes. This is the book I have always wanted. It goes through the protocol and tells you how it works. Then you download and explore the trace files to SEE how it works (or doesn't). I'm rationalizing my reading of the book in two ways: first, a good book on TCP/IP is recommended reading for the CCIE R/S path; second, it is oh-so-very directly job-related.
However, I do realize after reading the first book, I can't allow myself to be distracted from my CCIE lab studies. So I'm using this book as my "carrot" to encourage me to study. But this is definitely the book (read: reward) that I get to read after I watch my scheduled videos or finish a scheduled lab. Awesome stuff.
Posted by BlueWolf on February 28, 2013
November 25, 2012
Books - not so much lately
There's a post on my "CCIE Study Notes" blog that I want to talk about here. It's about how much there is to do to prepare for the CCIE Lab Exam. If you're wondering why there are no networking books on the Read List for 2012, it's because I'm focusing on videos and lab practice on remote racks. It's a lot of material and a lot of work.
The pictures on that post show three full pages of flip chart filled with a list of every task that I'm going through in the Workbook. There are 5 columns of about 30 lines each - for each page. And that is just Workbook I. Then I list all the videos (number and hours to complete) and then the number of configuration and troubleshooting labs that are found in the other three workbooks. It's pretty overwhelming when you look at it all.
This is something that you can't just do "in your spare time" as a hobby. You really have to focus and practice, practice, practice. I found that those pages of flip chart have provided a lot of relief. I can see my progress and it really keeps me going. I'm also using it to plot my rack sessions and make better use of the time. But it still takes a long time to complete it all.
This is a test of stamina as much as a test of skill.
Posted by BlueWolf on November 25, 2012
November 14, 2012
What if you could pay a certain amount of money, and with some effort and practice, make your skills sharper and build confidence? Would you do it? I guess as long as the amount of money was within reach, most ambitious people would consent.
That's what rack time does.
I probably approached it the way most people do - it's expensive and I wanted to save most of it for actually practicing lab scenarios. In some wishful, magical way I would learn enough on my own to just schedule some labs and work through them. After all, I've been in this field for a long time and I do this stuff every day. I understand the material. Well, I tried that and it was a struggle. And in some ways, the rack time that I used was not as efficient as I had hoped. It also lessened my confidence rather than built it.
So I went back to basics. I returned to Workbook I and started from the beginning - to prepare for my 2nd shot at the CCIE R/S lab. At first it seemed silly. I felt like I was giving myself a pity party or being too soft on myself. But in a very short time, I found that not to be true. It was a very good decision.
The first thing that happened is that the first few exercises were easy. It was nice to start off and be able to knock it out of the park. The easy stuff. That part did not build confidence. However, it did get me to appreciate the things I did know inside out. Then I hit a section that I wasn't strong enough on to complete. Ha. It was something that I know about, but don't use in my everyday experience. Wow. Hey, there's a lot of stuff here that you don't use in every workplace every day.
So when I hit that snag, I broke off a piece of it and worked it. I practiced figuring it out and then I blogged about it at my other blog. Having to write about it helped me to iron out the wrinkles in my understanding. I had to understand it enough to clearly speak on the topic. And with this being public, well, you're going to really make sure you're getting it exactly right. Which brought me to the documentation a few times to check my post. I learned enough through this to be sure of what I was posting. Then I went back to the rack and re-worked those sections again. Now I'm more sure of being able to configure it without needing to rely on notes or documentation. I totally understand it now. THAT is what built the confidence.
Granted, I'm not yet scheduling time at RTP for that 2nd shot. But after having that experience (my first attempt), I now know where I need to be to realistically have a chance at passing. And I can see my knowledge, skills and experience build with each rack session. And I have a "method" of study.
One other thing that I found helpful when practicing - don't struggle. If you're working a section and you're feeling like it's a stretch, then drive forward. But if it feels like a struggle, move on to another section. This will help conserve rack tokens. Struggles take lots of time. Learn on non-rack time. Then go back to the rack to practice what you just learned.
For example, the other day I was able to configure the 'basic' parts of RIP. Then some of the more advanced tasks were in the later sections. I started to get frustrated. Frustration is not what you want to practice. So I made a note on the sections that gave me trouble and moved on to EIGRP. I loaded the next config template and in 12 min was back on track. I started to configure again and made much better use of that rack time. After my session was over, THEN I went over the advanced scenarios and reviewed the documentation.
And once I practice it again and blog about it, the other benefit is: I can put that to bed. That's what came out of my first attempt - the ability to know when I know something well enough to move on to the next topic.
Time Management. It's a soft skill - and although it's not explicitly tested on the Lab Exam, it's a part of it. Practice it before the test and it will become a part of you. These are all skills that you need to take with you to the test.
Posted by BlueWolf on November 14, 2012
August 25, 2012
I don't normally "re-blog" but I found this article quite interesting --
20 of the Best IT Security Lessons Ever Learned by David Spark
It grabbed me with the first one:
Tip #1: Security must enable business, not prevent it
and then really hooked me with:
Tip #4: Teach the basics again and again
"you can be far more effective just educating personnel about simple secure practices, over and over again"
Tip #11: In a business vs. security battle, business is always right
Which shows a guy holding a chalkboard that says "There is no security risk. It's all business risk."
Good article. The first point - omg, isn't that an old concept? Remember this book? You may not like or agree with Gates, but read this and realize this was first published in 2000. He was telling businesses that you need to leverage your geeks to give yourself the advantage. And he was also telling geeks that they need to provide business value - not just geek giggle. I remember that time in computing. I had gotten my MCSE in 1998 and CCNA in 1999. The 'big thing' was what you could do - not what you should do. Projects were created just to prove you could do something, not because they had any business value. Heck, we'll figure that part out later - let's see if we can make it work first. And then a few years later, the tech bubble burst and everything changed. One of the reasons I went for the CISSP is the focus it has on business rather than pure technology. Granted, I have the technology background - it's not enough (for me). Fellow Geekateers - wake up! The businesses are where the MONEY happens to be... remember? We work FOR the business, they are not the enemy. They are not the people who are making our jobs difficult; we are making their jobs difficult. You have to make the secure way the EASY way of doing things, or else you will get someone somewhere going around the system. Or if you are that immovable block "protecting" the network - yeah, you can be removed. (Psst - the business will see to that.) And in security, all you need is one weak link to break the chain. Just one person (especially an insider) with a reason and perhaps business permission to circumvent the controls and you have just opened the door to someone following behind them.
So now about #4 - that's a favorite of mine too. You have to teach the basics - and not just nag. You have to get out there and talk to people and train them to think securely. You will not be with them all the time. You will not be able to train them on everything. They will not remember everything. So keep it simple and teach the principle of the matter. Teach them - if YOU can access it, then a malicious user can access it - with your credentials. That way people can retain the idea and apply it to new situations - like when you go from one type of credential to another...["well, I know you shouldn't share your password, but I just let him have my ID card for just a few min to go to the bathroom..." ]
And again...#11... that business thing. The guy with the sign is right. It is ALL business risk. From security to maintenance - it's a business decision.
However - the place where I see both security and business falling down is the reluctance to identify data with different levels of business importance. Business doesn't want to pay for security to take the time (or their time) to properly identify business value. And security wants to secure everything. It's a WASTE OF MONEY to lock up a head of lettuce. I've seen time and again (at a number of companies) where they have a blanket level of security over everything. Sometimes it has been so severe, that many people can't properly do their jobs. Or they waste vast amounts of time employing (or going around) the security measures to complete a simple authorized routine task. At the same time, business-sensitive data is treated the same as all the other data on your network (in the belief that it's all locked down). Is it really secure? If everything has the same level of security and you just got around that security to do some routine task... what about the sensitive data?
There's one tip that they left off - or perhaps may be #21:
Bad security is worse than no security.
If you think you're secure and you have bad security, you won't bother to "fix" something you don't see as broken.
Posted by BlueWolf on August 25, 2012