There has been a lot of advice about graduate school given in many different forums. The three advice articles provided in class this week. Each article took its own tack, but in all, it boils down to a few common themes.
Ron Azuma gives wonderful, thematic advice that really applies to any kind of graduate student. The first question that you must pose is "Why the hell am I doing this?" He's right in reminding us the if you don't know the answer to this question, you probably should stop wasting your time and go do something else. See, graduate school does not fit into the pattern of education that everyone thinks that they understand.
· B.S. = Bull Sh*t
· M.S. = More Sh*t
· Ph.D. = Piled Higher and Deeper
The common thought is that you learn stuff in you r undergraduate career, then for your Masters Degree, you take more classes and learn more stuff. Finally in the Ph.D., you learn the rest of the stuff and can be called an expert, or professor or magically be able to teach classes and do research.
The reality is that this is far from the truth. There are two different kinds of Masters Degrees - one where you learn "more sh*t" and then go back out into the workforce and are able to do more than someone who just has a bachelor's degree (maybe). The other kind is this academic masters as a stepping stone to (or from) a Ph.D.
Of course, this is all program dependant. There are some Masters Degrees that are require d stepping stones for the Ph.D. For instance, in many Engineering programs, a Masters Degree is required for admission to the Ph.D. Program. Many others require students to complete a Masters Thesis and receive the degree as a matter of course halfway through their Ph.D. program. However, some have a Masters as a bail-out option for those who won't be finishing the full program.
Looking at things in terms of earning degrees still doesn't give you the right picture. Graduate education is not about being taught a certain body of knowledge, regurgitating this to pass classes and exams, but it's more about being able to ASK the right questions and discover those answers through the conduct of research.
How does one learn how to do that research? You do it by performing the research. You do it through apprenticeship. You do that through the sheer effort of doing the work on your own. Of course, that doesn't mean doing it on your own all of the time. You need help. You need advice. You need your advisor/mentor and your peers. You'll learn, though, by doing.
So, that brings me to three more resources that I found helpful and thought I'd share:
First is a podcast that I listen to. Well, I don't listen to all of them, but this one caught my attention. It's an interview with Dr. Ron Evans from the Salk Institute. In the first half, Evans talks about science and graduate education, in a very pure sense. Graduate education is not about learning more stuff. It's about learning how to ASK and ANSWER questions. The more you do that, the more potential you'll have for being able to ask the RIGHT questions. About 25 minutes into the interview, it really gets to the point about asking the right questions. Evans discusses his experience with Francis Crick (of Watson and Crick - the co-discoverers of the structure of DNA - yeah, those guys) - and how Crick had the ability and interest to find the good and right questions to ask.
The next item is a book recommended to me by one of my favorite undergraduate professors, Dr. Chris Hoadley. When I first talked with him about applying to graduate school, he recommended a book to me - Getting What You Came For. This book is very helpful to the new graduate student- especially in the pivotal first year transition.
The last item that I'll recommend is a book that was recently recommended to me - The Craft of Research. This is a wonderful book that is more about the "how" than the why. The mechanics of doing the literature review, the concepts of how to figure out the right questions to ask and how to turn them into research and publish it. I'm hoping that when I have time to finish this book that I'll have a better understanding of HOW to do the work, not just the WHY.
So, what didn't I expect to see out of all of this advice? There was a gem that caught me off guard. Alice Dreger's article comments on travesties that happen during graduate school. Her advice is to understand that it happens and is normal, but you need to overcome it, get past it, and get on to the business of doing the work that you're training to do. Even if that means figuring out what to do if your advisor is having a relationship with one of your peers. The implication in Dreger's article is that the relationship is inappropriate - well, duh! But more importantly, you have to realize that your adviser is human as are your graduate student colleagues. Even though there are rules against such behavior - it still happens. It still affects other people - and if you are caught in the middle of such things - IT DOESN'T HAVE TO BE THE END OF YOUR ACADEMIC CAREER - especially if all you're doing is your graduate work and it's the other people with the inappropriate relationship. Your career doesn't have to be collateral damage. Don't let it be.
Today, I am going to tell you about one of the organizations that I am involved with and what we've done over the past couple of weeks.
See, I am a Boy Scout leader. I serve as the Cubmaster for Pack 23 in Pleasant Gap. Our most recent pack meeting, we had two presenters from Trout Unlimited come to talk to the boys about fly fishing. The played a short movie about what it is like to tie flies, catch trout and release them back into the stream. Of course, they showed the whole life cycle of the trout - from fertilization of the eggs, through each part of the life cycle. It was really cool to see baby trout hatchlings come out of their eggs, and drag their yolk sacks along with them. I had no idea. Neither did the boys. They thought it was great. Of course, they really liked watching the part where the fisherman had the trout on the line and it fought and danced and jumped until he finally brought it in... where he could release it back into the stream.
As the Cubmaster, I play the role of the Master of Ceremonies for our pack meetings. Once a month, I'm up front, leading our boys through the presentation of the flag, pledge of allegiance and other formalities. I also get to present the boys with their awards they earned. Whether it's a simple bead or belt loop or a big award like an advancement in rank, it's nice to see the pride on their faces when I call them up to the front to get their award in front of everyone.
This weekend, our older scouts - the Webelos Scouts (4th and 5th graders) will be going on a hike with the same aged boys from the pack in the next town over. It will be a great time - I'm sure it will be cold, but for a couple of hours - there will be no video games, no T.V., no school, no messy house. It will just be the kids and the parents, hiking along part of the Allegheny Front Trail.
Not all of our hikes are in the "Great Outdoors." Just this past weekend, we completed the "Scouting for Food" drive to collect canned goods for our local food bank. The week before, we put plastic bags on each door in our town. There was a note inside, asking people to put the bag out the next Saturday for pickup - with a few canned goods or other non-perishable food items like pasta or mac and cheese - whatever they can spare. Our boys collected these items and we took them to our food bank, right in town. Our pack of cub scouts and our boy scout troop (boys ages 11-18) collected 3073 items for the food bank. This will help feed the 25 families (a total of 75 people) who seek assistance from the food bank for the next 2-3 months. What's really cool is that scouts from all over the county did the same thing on the same days. We helped to stock the food banks in State College, Bellefonte and surrounding communities.
So, what did that cost me? Nothing, really. It was just a few hours of my time on each of those days. I got to spend that time with my son, Stephen, too. He's a good kid and he likes to help our community. It's good to see him grow and become a young leader. He enjoys scouts and I know that these times will stick with him, as my years as a youth in scouts stuck with me.
I write this week about a famous person in the field of information security. Eric Cole completed his undergraduate and masters degrees from the New York Institute of Technology. He went on to George Mason University, where he completed is coursework, but not his dissertation. He later received his Ph.D. from Pace University. After graduation, Dr. Cole went to work for the Central Intelligence Agency where he was the Internet Program Manager and computer engineer in the office of security.
Dr. Cole has written and co-authored many books including:
Hackers Beware
Hiding in Plain Site
Network Security Bible
Insider Threat
Cyber Spying: Tracking Your Family's (Sometimes)
Secret Online Lives
Network Security Fundamentals
Hiding in Plain Sight: Steganography and the Art of
Covert Communication
SANS Security Essentials
Network Security Bible
He is also the inventor of over 20 patents.
So, his publications are not in the peer-reviewed academic press, but his books are certainly on the bookshelves of more people than the number of people who will read the articles that many of us will ever publish.
What I admire about Dr. Cole is that while he was doing all of this work, he realized that none of it mean anything unless people were able to take action on what he knew. He helped to found the SANS Institute, an organization that teaches security curriculum to computer professionals. When academia moved slowly to the world of Information Science, Cole and others moved quickly.
They realized that professional education in actionable methods were important. However, the companies in industry weren't doing the job. Companies like Cisco and Microsoft had their professional certifications on their products and there were some low-level vendor agnostic programs for technician certification (Comp-TIA's A+), but there was a large gap at the professional level, especially in security.
So, at the risk of irritating both the vendors and the academics, Cole and others started teaching their own curriculum. They developed it, rolled it out and starting teaching seminar style with week-long classes. Sure, they were paid well - the average SANS class costs $5,000 per person to attend for the week and SANS now has an estimated annual sales of $30M - but face it... it's hard to pull together a good class with solid resources and get people to come back again and again.
Today, Cole is a senior scientist with Lockheed Martin Information Technology (LMIT) and Lockheed Martin (LM) fellow. He also is the founder and CTO of Secure Anchor Consulting, which is basically his consulting and outreach mechanism. So, between Lockheed, SANS and Secure Anchor, Eric Cole lives the life of teaching, research and outreach - the three functions that a tenure-track professor in any university does.
Oh, and how old is he? I can't seem to locate solid information about his age. I guess he learned a thing or two about keeping some information private when he worked at the CIA.
First is Computers and Security. This journal consistently publishes articles that I am likely to cite. There is a good mix of articles covering specific technologies, legal aspects, as well as usability concerns. For instance, in this quarter's issue - there's an article about "Interpreting the legal aspects" of security, another one about a specific protocol recommendation for SMS (short message service, one about neural networks used for intrusion detection, another about intrusion detection using attack graphs to correlate individual alerts and two articles about user authentication from a high level.
Apparently, the top journal in the field is the Journal of Computer Security. This journal focuses on the research that will have lasting impact. What is interesting about this journal is its assumption that its readers have a solid understanding on computer security. So, the background informtion required in many other journal publications is not necessarily required. The articles and succinct, dense and direct. That's kinda scary, but I hope that I can be one of the people in the world who can 1) understand what's in this journal and 2) one day publish in it. Guofei Gu's Computer Security Conference Ranking and Statistics page gives a good outline of the conferences and workshops in the computer security field. Just a quick look gives one the idea of the breadth of the field of computer security. There's so much out there from authentication to cryptography to secure software development to malware and intrusion detection. There's no wonder we don't have a good handle on computer security as end-users - the academics are all over the place, too. Maybe that's just an indicator of how difficult of a problem computer security is.
So, there are parts of this community that I am not as interested in, from a research perspective. For instance, I'm no cryptographic researcher. Heck, those guys are like real math geeks. I think cryptography is cool, and I have a lot of interest in USING cryptography. I may have an academic interest in the usability of cryptography in organizations and in complex, interconnected systems - but as far as the cryptographic algorithms go - I'm leaving that to the math geeks. So, that knocks 2 of Gu's top 6 conferences for me.
The ACM Conference on Computer and Communications Security looks very interesting. This year (in just a couple of weeks) the conference will be in Alexandria, VA. Dr. Patrick McDaniel, from CSE is one of the technical program chairs. He also has two students presenting a paper this year, "Rootkit-Resistant Disks" presented by Kevin Butler and Stephen McLaughlin. So, just taking a look at who is presenting a this conference has already given me some insight into a community that I want to be involved in. I might even see if I can break away to attend this conference - since it is relatively nearby.
The Usenix Security Symposium also looks interesting. The technical sessions ranged last year from in-depth concepts like cold-boot attacks on encryption keys to more widely generalized topics. Check out this lead-in: "In a field with few design principles ("defense in depth"? separate duties?), few rules of thumb, no laws named after people more influential than Murphy, no Plancks or Avogadros to hold Constant, and little quantification of any sort (we count only bad things), it appears the best we can do right now is to tell stories." See Mark Seiden's talk for more. I know I'll be listening to the MP3 or watching the video later. OMG! This is great stuff. Someone actually acknowledges where we really are in terms of policy, process and the industry (in terms of application and implementation) as whole. Last year's symposium had a number of co-located events - like the Security Metrics 3.0 Conference and Workshop on Hot Topics in Security '08. Both of these conferences have wonderful topic sessions - like topics in authentication, security, use of encryption, password usage, and lots of other cool stuff. Oh, and guess who from Penn State presented there last year? You guessed it - Patrick McDaniel! Hmm... maybe the community (or at least a part of it) is closer than I thought.
Finally, the last conference community I'd like to be a part of, eventually, is the IEEE Computer Society Technical Committee on Security and Privacy. This is a more high-level conceptual group. Although last year's program included a number of "in the trenches" kinds of papers - the focus is on the future directions of these topics, not on the nuts and bolts. So, trust and privacy in Web 2.0 is a common theme from last year's conference. So, I'm sure I'll get to this conference eventually, but because it is focused on a higher level rather than more mechanical, I'm probably not going to be publishing here anytime soon.
So, that's the long and short of it. I'll have to use Gu's list to check out the conferences that are lower rated. There's probably lots of interesting stuff there, too!
I interviewed Ben Hellar. Ben is a 4th year Ph.D. student who is also advised by David Hall.
Ben wasn't in the inaugural class as an undergrad at the School of IST at Penn State, but he was in the very next class. He was in the first recruited class at IST. Ben has seen the College grow from its infancy, move into its new building and create its undergrad program from scratch. If you ripped into the walls of the IST building - you'd find his signature on an I-beam somewhere inside - literally!
Ben was a Schreyer Honors College undergraduate. He completed an honor's thesis and took many honors courses while an undergrad. He even pursued the combined Bachelor's/Masters program for a time, but found that his interests were more aligned with the Ph.D. program than the Masters, so he graduated with his B.S. and entered the Ph.D. program. His original adviser was Dr. John Bagby.
Ben spent his first two years of graduate life finding his topic and interests. He has now found a home with Dr. Hall and Dr. McNeese where he looks at Human Performance Simulation, especially in crisis management, military situations and those that require formalized C3 (Command, Control and Communications).
Ben is currently working on the NeoCities simulation project. This project simulates Police, Fire and HazMat crisis management dispatch and resource allocation. He's studying team decision making and collaboration, especially of dispatchers and decision makers who would manage crises. While the tasks are oversimplified, they are done that way to specifically study the interactions of the people involved. The output of his research would fit into models for Homeland Security, the military, and crisis management organizations. Ben's dissertation will be focused on the overload problem in regards to the pace of events that occur.
Ben has published three conference papers. Two were born out of his literature review. He has presented twice at the National Symposium on Data Fusion and Sensing and once at the Cyber Situational Awareness conference at GMU. The second conference had a "tougher audience". These attendees were more technical and entrenched in the "T" part of the ITP triangle. So, Ben's research was along the lines of the T-P part of the triangle - and it was hard from them to get the idea that you needed to understand the people side of things - or that there even was a people-technology component to consider.
Ben is very different from me in many ways. First off, he is a more traditional student - going to graduate school immediately after (or, technically during) his undergrad experience. He's considering going out into the world to get more experience after he graduates. However, I guess we're really similar in that we both value that real-world, hands-on experience. I think that this will help Ben to focus his future research and make it more applicable by adding the realistic perspective. The order that I have done things is very different, but it really does point to the same thing - we need to combine academics with a reality perspective. Because Ben and I are both Penn State graduates, it will be interesting to see where we land later in life.
So, you've all heard people talk about a computer crashing.
I want to describe to you what happens when a server crashes at a medium-sized
organization.
This particular crash was interesting because the server wasn't completely dead. Sure, we've all had power supplies die, hard drives crap out, BSODs
and other kinds of issues happen. Those
are usually complete either-or propositions.
Either the machine works or it doesn't.
Very seldom do we have the situation where the system works - sorta-kinda. Well, that's exactly what happened in this
situation.
The server in question is four years old, with a three year old Dell Powervault PV-220 RAID-5 enclosure. It has 1.5 TB of data on this drive, storing user files and research data. So, with the 8 hard drives in the array, one of them is a hot spare. Because it is RAID-5,any one of the drives can fail, the hot spare comes online automatically and rebuilds the RAID. Well, that's what is supposed to happen.
I did have a drive indicate possible failure, but it didn't swap out. The server started serving out a number of corrupted files from this drive and a normal (non-raid) drive. Upon reboot, the drive system showed six of the eight drives as having completely failed. That's not supposed to happen either.
I was able to force the drives back into an online mode - and bring the array back online, but the NTFS file structure was corrupted. The server needed about 72 hours to rebuild the NTFS structure. Unfortunately, we needed the server to be back online within 12 hours, so we forced it back up the next day after the crash. The data on the RAID array looked like it was completely rebuilt and some files were lost to corruption, but it turns out that halfway through the next day, that we realized that the drive wasn't rebuilt correctly, and wasn't stable... users were losing files and directories throughout the day.
So, back to square 1 - and we brought a new server online with the backup data. However, guess what - the backup wasn't completely up-to-date. Some files were 2-3 weeks old, while others were completely current. So, 2 days later and we bring up the backups that are not current - yeah, people were just short of screaming at me.
That's all fine in my mind - because people should be making their own backups of their own data. That's what I tell them to do, but not everyone listens to what I tell them.
I was able to bring up the old server with the suspect drive the next week - ran the rebuild over the weekend. While there was file corruption on individual files, I was able to bring back some files that people had lost. Others recovered lost work within a day or two of re-doing what they had done in the past couple of weeks.
The crash has taught me a couple of things:
Most users will not do their own backups. They rely on systems too much and make assumptions that nothing will ever go wrong. While this is a bad assumption on the user's part, it *IS* the base assumption that most users have.
IT Managers must live up to the user's expectation, regardless of how unrealistic that expectation is.
There is a middle-ground between a system working and a system failing. That middle ground sucks.
Disaster Recovering Planning needs more attention in small-to-medium sized organizations. Something as simple as a single server crash can highlight faulty backup processes, required services and end-user expectations.
Oh, and Murphy's Law applies to IT. The server crashed 30 minutes before my IST511 class where I was supposed to do a class presentation and could not miss.
So, maybe you're laughing right now. Maybe you're thinking, "Gee, so what's new?" Maybe you're thinking, "I'm glad it's not me!" Whichever your reaction - I hope this blog post has made you think about how you back up your important data. Having a solid, reliable, reproducible, transparent and easy-to-use backup system for things that are important to you is a key ingredient in your ability to survive even the most complicated failure.Maybe I should post my philosophy on how to back up your data for your own protection... watch for that blog posting later.
Recent Comments