It needs Focus

To be a scientist, you don’t need necessarily get a PhD. But doing a PhD is a good practice to learn that being a scientist does not need genius but needs focus.

Although I write this blog for scientific and academic discussions, I want to abuse it a little bit to report a workshop I recently attend. I went to Grad Cohort workshop in Seattle, which was generously sponsored by Google and Microsoft, and arranged by CRA-W. The workshop’s goal was to train women in computing science to have a successful academic life as a PhD (or Masters) student.

So back to the requirements to be a scientist, I learned in this workshop that although I feel I am a hardworking PhD student, but it might be a myth. I learned probably I am doing my PhD horribly, very horribly. By horribly, I mean I am wasting too much time, I am not doing research by its real meaning, and I am slaving myself while I could do things in a much easier fashion.

For example, in a time management session, the speaker shocked me by telling us that checking e-mails is the most time-consuming task we do in the entire day, even when we are not in our offices. We open our mailboxes several times, and by several I mean a huge number.

So I’d like report back some of tips that I found useful, for all ambitious students, scientists, researchers, or scientist-title seekers:

- Don’t check e-mails in the morning. You are scarifying the best best best hours of the day on nothing. Honestly, it is really hard: We, people in computing science, wake up in the morning with a hand searching for the power button of our laptop, and the other hand may be searching for glasses to read the e-mails. So I started with this practice: I open my mailbox, but I just look for very important e-mails, like ones from my supervisor. I don’t read spam-like ones, I even delete half the e-mails that I guess I am not going to read any ways!!

- Practice Time-Sink Finding for two weeks. I started doing this. Every 15 minutes record what you did in that last quarter of hour. Don’t think it is a stupid test, and don’t think you should start doing it when your deadlines are over. At least I promise you due to the Hawthorne effect you work much better, because you are observing yourself, and you will feel the Hawthorne effect on yourself. The findings of this experiment for me is amazing: I put more time on hanging out with my labmates, friends and colleagues than doing research. I don’t know how my friends would feel about it, but I and my supervisor would seriously think about it!!

- Put some time on deep thinking. I have not yet started doing this, but I am sure it is a good advice.

- Have a place to hide: When you have a deadline, a very important conference is coming, or your PhD Qual exam is approaching, you should have a corner of a library that no one knows you (probably social science library is an option !!). I have such a corner, but I can't reveal its name !! You go there, don't move, work for 12 hours in a serial!

Ambitious Science or Feasible Engineering

Working on secure protocols and modeling approaches to them is still under progress. However, a more abstract question draws my attention: Will goal modeling really work for us? The idea is to develop a comprehensive model of goals and intentions of actors, roles, and stakeholders, tasks they need to achieve their goals, resources they need, dependencies of actors on each other, and finally consequences of each task or goal or dependency on other goals of all actors. Suppose we have such a complicated chain of goals and dependencies and consequences. Then, this model could do magic. It can answer many questions: will a particular actor achieve his final goals? And if not, why? Who causes the failure or success. But, we supposed we can have such a goal model. When it comes to real human agents and their goals, it may be very ambitious to say we can develop such a model. Here is the problem: can goal modeling be developed to a feasible engineering process?

And what happened that this question came to my mind? I am developing models of knowledge processes in a hypothetical organization. I’d like to express who generates a body of knowledge and how stores it, and with whom the knowledge is shared, and “Why”. I tried goal oriented notations to model the knowledge market relationships, and then I realized I am going deeper and deeper into the goals of the actors. I think one may never stop digging the goals of a human agent for sharing or withholding a piece of knowledge (or any thing else), and you will never have the ideal comprehensive model.

To search for a comprehensive model

These days I am thinking of a way to relate sequence diagrams to goal models. First, I’d like to increase the understandability of protocol specification, then I am looking for ways to verify the protocol, or at least do some trade-off or security analysis on it. Even alternative ways to perform a part of a protocol could be analyzed. As I said, sequence diagrams don’t say why we send a message or a value, and why we encrypt them. Goal models answer these questions, but they can’t express the sequence.

I guess I have told this story before. Today, I found a new way to express sequences of activities, events, and branches by Use Case Maps models. I don’t want to go into details of this modeling approach. Just, I’d like to mention they don’t express what messages are sent and received by components and activities. That’s a very considerable lack for expressing protocols, specially security and authentication ones.

In sum, it seems when we are modeling, we are losing to express some aspects to express some other ones, unconsciously we are making trade-offs between expressiveness from competing points of views. One may wish to have a comprehensive, mother, complete model, that expresses the whole aspects: goals, sequences, messages in my case. I am wondering, that ideal, and dreamy modeling approach, would result in very complicated models.

May be abstracting concepts from each other is a good thing. Abstracting temporal aspects from goals might be a good choice if having them both together is just not readable. However, there should be mechanisms to relate these two views of the system together easily. Even there should be ways to view a fragment of the system from the point of view of combination of more than one abstractions: for example, looking at a limited portions of the system from goal and temporal aspect.

Insights into modeling security protocols by goal oriented models.

As I said earlier, I am working on goal oriented models for security concepts. I’d like to show you what a goal model is. Here is an example of a goal model developed by i* modeling notation. As you can see, this approach to modeling the systems supports goal and tasks decompositions, expressing dependency chains, and impacts of goals in each other.

Goal oriented models, often do not contain temporal information. This makes them the worst choice for expressing protocols, since the first required concept for modeling protocols are concept of sequence. But why I am still interested to express security protocols by goal models? An authentication protocol can be very complicated. A description of the protocol and sequences of messages may not be untreatable as long as you don’t know why a message is sent to a party, or why it is encrypted or why it is not. Also, it is interesting to know due to threat of what kind of attack or security goal a message is encrypted. This may help first understanding the sequence diagram of a protocol, and then it opens doors to further formal verification. Here where I need to study BAN in more detail.

Specifying Security Protocols by Sequence Diagrams and Goal Models

Cryptographic protocols, especially ones for authentication purposes, are complicated and hard to understand if you read the sequences of plain or encrypted values that the parties send back and forth. But are they understandable for a machine or tool that verifies the security and vulnerabilities of the protocols? There exists very interesting research on formal verification of security protocols which mainly results of work of three people: Burrow, Abadi and Needham, developers of the BAN logic. Their approach to security protocol verification consist of formalization of the protocol messages; specification of the initial assumptions and protocol goals, and finally applying logic to find flaws in the formally specified protocol. The whole idea is so cool. They have defined semantics for specifying believes of parties of protocol and their goals.

I am not a security expert, and probably I will have a hard time understanding this approach. However, I have some ideas to improve the understandability of specification of protocols and goals of messages sent and received, by relating the steps of the protocol to goal models. Goal models, which basically I spend most of the time playing with them, capture and express “why” in addition to “how” and “what” aspects. A famous goal- and agent-oriented modeling and analysis framework in this regard is i*. Currently, I am thinking how to express a protocol both in sequence diagrams and i* models to improve the semantic and also understandability of the models.

Software Requirements come first or Software Architecture?

Traditionally, requirements engineering paradigm has promoted the idea of separation of problem space from solution space when thinking about the requirements and design solutions. In this way, analysts do not bother to think of how, when they are focusing on what, and later on they look at the list of requirements and come up with an architecture design for the mess of requirements. It has been counted as good thing. However, for a reason I don’t know, always someone comes that says, oh no, you have all been so wrong. Twin Peak, which is an iterative process model, inspired from Boheme Spiral process model, suggests architecture and requirements should be developed in parallel and iteratively.

I like this idea, and I’d like to find a way to prove it. I have convinced myself with reasons, like: if we gather a list of requirements without thinking of their feasibility, we have just developed a wish list, not more, not less. They are not software requirements that in the next phase a designer develop them. In addition, when we close eyes to solution space, we may guess that some requirements are in conflict, usually happens for privacy and security. However, the impact and interactions of requirements on each other, do not come from the nature of requirements, but come from the nature of solution that implements the requirements.

To start

I wish to be a scientist, though due to the nature of things I am working on I will never be eligible to win a Nobel Prize, I still want to be a scientist. The ironic point is that my field of study, Software Engineering, seems to be useful to very limited group of people in the world: software companies, programmers, and software developers. I won’t cure any disease, I won’t discover a new planet in the corner of the universe, and I won’t even build a new machine or technology.

So, as my little tiny PhD studies move on, I am discovering that there is no revolution left. I sometimes feel I am sitting on a sofa, or at most behind a monitor, and I am making theories about how softwares, specially the secure ones, are being developed, and why they fail, and what we should do or not to do to prevent the failure.

I am not a security expert, but I am interested in developing secure software systems. Even more general, I am interested in general system security, and in particular case of Software Engineering, which is the area I am doing a PhD in, I am interested in security requirements, attack modeling, vulnerability analysis, countermeasure analysis, trade-offs among security and other goals such as privacy and usability.

I have crazy ideas to start a revolution in secure software engineering, and I have little tiny ideas to move the discipline an epsilon ahead. This Blog is where I am going to talk about them, since my PhD thesis does not have enough space for all that crap.