I am going to start Ph.D (software security research) very soon. How can I prepare for that. Please recommend any tools or softwares that I need to familiarize with before stating the Ph.D. Any advices other than softwares?

6 Answers 6


I went back to obtain a PhD after years of working in industry and based on that, it would have helped up front for me to familiarize myself with the following things:

  • LaTex, for your eventual thesis but also for the papers you'll probably need to publish. Luckily, there is a StackExchange site for Tex.
  • The conferences and journals in your field. It helps to look at the papers your supervisor has published to see what they are. You might want to read some of the proceedings as part of your literature study.
  • Literature sites and tools. You'll need to manage a large bibliography and sites like DBLP and Google Scholar will be useful, along with tools such as JabRef.
  • Technical writing. It's typically useful to turn your initial literature study into an Annotated Bibliography paper. Regardless of whether you end up submitting it somewhere, it at least helps in structuring your research and teaches you technical writing.
  • Paper submission systems such as EasyChair and CyberChair. It won't be immediately important, just make sure you don't start figuring it out an hour before your first paper is due :)
  • 1
    For writing in general, I can't recommend enough that all new PhD students read George Gopen's The Sense of Structure: Writing from the Reader's Perspective.
    – Macneil
    Commented Apr 22, 2011 at 14:14

Please recommend any tools or softwares that I need to familiarize with before stating the Ph.D. Any advices other than softwares?

That doesn't make any sense. Your ability to succeed in a Ph.D. program does not rely on knowing X or Y piece of software. It relies on your analytical skills. That's what you should be worrying about.

I once worked my way towards a Ph.D with a focus on computer security and distributed systems architecture, but I ended up dropping in the middle of my M.S. thesis to work full-time (big mistake.) 11 years later I'm back in grad school, and I've had a lot of time to think about what I did right and what I did wrong. So, from my personal experience, this is what I would suggest to you


The only software I would worry about learning are those for keeping bibliographical references (such as BibTex or EndNote... though publishing houses like Springer-Verlag provide free accounts for keeping references.)

Actual Skills Needed

You should be worrying about technical writing (possibly with LaTeX, but MS Word has gotten quite good for technical writing), research skills, analytical skills, mathematical and logical skills (in particular Mathematics as pertaining to Computer Science as well as Mathematical Logic in general.)


You will be writing and researching a lot. A lot. Expect (and pursue) to write technical reports for publishing internal to your university. Use those as preps for preparing papers that you'd like to submit to conferences and symposiums.

With that said...

Be Cohesive

Avoid writing about many divergent topics. Obviously this might not be within your control as your graduate advisor might ask you to switch topics. Furthermore, at the start, you need to explore different topics for your eventual dissertation. But as you work on, you should (read must) begin to narrow the focus until you pick one broad topic from which to work your dissertation.

So every paper that you write and every experiment that you conduct should help you execute your research towards a dissertation. You should have a dissertation idea by the 2nd year (and you should be actively working on a definite dissertation topic before the end of your 2rd year or around the time you take your qualifiers exam.)

Be Precise

When you write, be precise and unambiguous. Let me make an example out of thin are, just for illustration purposes.

Imagine you write a sentence like this:

"The behavior of XYZ system depends on its communication semantics"

What the heck could that possibly mean? That would be very obvious for the writer, but not for a potential reader. You will find yourself writing such things at a time. To avoid confusion, and to increase the chances of your paper being accepted in a conference, you must remove ambiguity by declaring what terms and phrases mean in your paper:

"The behavior of XYZ system depends on its communication semantics. By 'behavior' we mean how the system responds to an attack under abnormal circumstances such as rapid changes in user traffic. By 'communication semantics' we mean the architectural paradigm and technologies used for enabling communication between components (such as RPC vs message-oriented middleware)".

Don't worry if any of that sounds like noise. It is. I simply pulled that out of my ass. My point is that, when you write a paper, you are going to define things according to how they make sense in your paper, with respect to the topic you are presenting. Make sure that everything you refer to (or introduce) in your paper is actually defined somewhere. In other words, if your paper says "X" somewhere, somewhere else (and in one single place only) you should also say "by 'X' we mean this and that".

CS Math

Do not underestimate the need for understanding complexity theory, algorithms, software engineering and architecture, modeling, the complexity of building experiments, and, most importantly, discrete mathematics (in particular about relations, axiomatic set theory, mathematical logic (both propositional and first-order) and the mathematics behind security models.

Work on your Argumentation Skills

One thing my RA supervisor did was to put all of us RAs into a weekly round table (he would participate himself). He'd pick a random topic, and (yep, also at random) would partition the group into two sets - one assigned to defend the paper, and another one to attack it. Notice that we were assigned to defend or attack the paper before even getting a chance to study it. We had only one week to read and prepare our arguments.

One thing that taught us was to 1) really and deeply read a paper, and 2) exercise our ability to build arguments.

Background Knowledge

Since you are going into a Ph.D with a focus in software security, I will assume you know about the works of people like Ravi Sandhu (in particular on access control models), or Edward Amoroso. If you don't (and if your research group hasn't given you background material to read), you should start with that (and I'd strongly suggest you look into Amoroso's book.)

Also, you should look at certifications like CISSP, GSSP and ECSP, not necessarily to work your way towards getting those certs, but to understand the topics they attempt to cover. You should be aware (if just by a bit) about things like HIPAA and SOX compliance (and what they mean with respect to software security.)

If you are not familiar with web security, you should take a look at the OWASP page (and study the top application risks and their implications to security). You should also take a look at the security models of enterprise systems built with Java and .NET as well as common vulnerabilities in Unix and Windows systems. A cursory overview of SE-Linux (a "secure" linux sponsored by the NSA) as well as the security model of the Windows NT kernel architecture should also prove valuable.

In Short...

In short, prepare yourself to do a lot of reading in addition to your course load (and probably your first research assignment as an RA) in preparation to do your research work and Ph.D. thesis. You should not be surprised if it takes you about a year to go over all the basic material that I've just mentioned.

Good luck... btw, feel free to ask me any questions should you think I can help with something.


Do you know who your supervisor will be? If not and if you might have a say in it, get familiar with the staff in the department, the work they've done and ideally talk to some of their current students. Having a supervisor that just uses you for slave labour versus having one that mentors you well can make a massive difference.

  • If you pick an advisor you cant stand, you are in for years of pain, suffering and motivation-killing hate. Evaluate them for people skills as much as for technical skills, as you will spend a ton of time with them, often arguing.
    – Marcin
    Commented Apr 22, 2011 at 14:06

How can I prepare for that?

The short answer is that the tools that you'll need for paper publication and homework submission will be made clear to you over time. You're smart, you'll pick them up.

My suggestions are a bit more pointed towards life preparation:

  1. Get a strong undergraduate computer science education first. Seriously, a strong foundation will enable you to squeeze the most out of every minute in graduate school. In today's world, there are too many resources (e.g., MIT) to excuse a background that is missing fundamentals. You will still be surprised how many people hit graduate school without a fundamental understanding of algorithm complexity or data structures.

  2. Figure out how you are going to pay the bills. This is a huge one. I was going to chool full time and working a lab assistant / teaching assistant position at the same time. Reversing that (full time job and part time student) is another choice but you will be in school for quite a while. Graduate school takes years - you need to understand your financial plan.

  3. Have a serious talk with your significant other. Graduate school takes a lot of time out of your life. In my final year, I was working seven days per week from 6 AM to 6 PM. Almost all of the rest of my time was spent with my new wife (who stayed married to me anyway... ;-). It's worth thinking about your schedule ahead of time.

Be aware that that the schedule that graduate school requires will become progressively more annoying over time. It's hard to relate to normal people after a while....


I recommend the course documentation from your chosen university. Should list names and telephone numbers for getting information about the course (which you should probably have done before signing up for it).


I did a PhD in software engineering, and before that a research masters, so here is my two cents.

The single most important decision you will make is picking your advisor. This is not just a matter of research interests, it is a matter of personality and work style and there can be clashes. In my school, they called it a "marriage process" for a reason. And divorce is costly.

Get acquainted BEFORE you start. Read their webpages (which are often outdated). Read their recent publications. See what conferences they are involved in. Talk to pat students about pros and cons, etc. Figure out their expectations. Meet them if possible. Do this before you start. This is different than meetings you had in open house - now they're not selling you the place. Get the current grants they are under - that is where your funding will come from, and it will limit your research topic to a degree. If you have an advisor in mind, ask them what to read in advance and what courses to take.

Second most important - narrow down the topic. Again, read the literature. Understand what the evaluation criteria is and whether it fits your style and time frame. Going on the wrong tangent is the single biggest mistakes grad students make. I did it twice. Spent three years writing software and then did a user study. In my Ph.D., repeated the same mistake.

Next, work on your academic writing skills now. There are many schools that post course materials online on writing for academic journals. How to be terse. How to summarize, etc. This is a thing that you learn gradually, but come paper time it's better to focus on research, not on writing.

As for software: You probably understand LaTeX. Make sure you understand the main OS you will be using. Make sure to read VERY CAREFULLY what your university allows you to do in terms of research and network access, etc. You don't want to spring the lawyers.

Not the answer you're looking for? Browse other questions tagged or ask your own question.