Nahuel Beni’s Blog

This is the third post on a series of Threat Modeling post, previously I wrote about Information Gathering and The Modeling Process. On this opportunity I’d like to introduce you to a very useful tool provided by Microsoft, the SDL Threat Modeling Tool.

Creating Architecture Diagrams

Using Visio’s engine, this tool helps us in the process of creating Architecture Diagrams.

So, let’s take as an example, a simple system in which we have a SQL Server, a Web Page and the user which uses the page.

(This is a simplistic scenario specially thought for this example; it does not in any way suggest a way of designing or programming)

First, identify the components of the solution. In our example, we have The User/Browser (External Interactor), the Web Page (Process), and the SQL Server (Data Store).

(Let’s assume we have gathered all required information following the steps described in my previous post and move to using the tool, threat modeling)

Modeling with the tool is quite simple, just drag and drop the elements in the canvas (Visio-Like) and then join with the flow arrows.

Identifying Threats

The tool automatically generates “threats placeholders” following the STRIDE Chart, mentioned in my previous post, for each component and flow of the diagram. It also provides us with some tips to identify those threats.

NOTE: The tool also has TFS integration, so you will be able to open a bug (see “file bug” in the screen) directly from the tool.

At this point you should complete the placeholders for each element with the corresponding threat, or certify there is none for it. I’ll add one just as an example.

Let’s suppose that the webpage does not parse the user/password requested in the login. Then we have a SQL Injection Threat (could be either Tampering or Information Disclosure depending on the solution.)

At this point, we should file a bug, and, once the bug is closed, update the threat model with the corresponding mitigation.

There’s a lot more to investigate, I leave that to you

Hope you find this information useful; feedback and comments are always welcomed !

This is the second post regarding Threat Modeling. On the previous post I talked about information gathering before starting with the process of threat modeling per se.

On this second post I’ll explain that process in a theoretical way, and, on a future post, show how this can be applied using Microsoft SDL Threat Modeling Tool.

Threat Modeling Process

The threat modeling process has four main steps and it’s intended to help identifying those areas of higher risk within the application, and will also be useful for creating test cases on a future security test plan.

1. Identify threat paths
2. Identify threats
3. Identify vulnerabilities
4. Rank/prioritize the vulnerabilities

Identify threat paths

The first step is mainly summarized in my previous post, Threat Modeling - Information Gathering, the main objective is to identify overall threat paths (data flows and components) and gather knowledge that will allow us to define the threat level that each component or data flow has.

Identify threats

For each threat path, we should dig deeper on the processing done, and identify the threats of each individual process.

Identify vulnerabilities

The next step is to identify the actual vulnerabilities for each component.

For this I use the “STRIDE” chart but any categorization should work if you adjust it to your solution/company needs.

Rank/prioritize the vulnerabilities

Nothing that will require too much explanation here, the DREAD model is proven to be highly effective for this:

• Damage Potential: How much damage could this cause?
• Reproducibility: How easy can it be reproduced?
• Exploitability: How much effort is required?
• Affected users: How many/which users could be affected?
• Discoverability: How easy is to discover the threat?

Then add up the results and the higher DREAD scores should come first when fixing vulnerabilities.

Hope you find this information useful; feedback and comments are always welcomed !

In this post, I’ll explain the concept of Information Gathering, the first step for creating a threat model, and some tips to ensure the right data has been collected before creating the actual threat model.

Information Gathering

As said before, Information gathering is the first step to creating a Threat Model. During this process the following items should be identified:

• Entry Points to the solution.
• Assets to be protected from possible attackers.

For this process, you need to be certain that the whole solution is being considered (and not just a part of it e.g. the database,) a good way of doing this is:

• Reviewing the solution diagrams.
• Meeting with the architects of the solution.
• Analyze the solution with debugger tools.

Output

The output of information gathering, as you may have already realized, should be a complete set of architecture diagrams in which the different components and data-flows are identified. Especially those that come from the outside (should be least trusted.)

Sketching the architecture diagram

The architecture diagrams should be based on the documentation that is already created for the solution (remember not to rely in documentation), and updated with all information that comes up after reviewing them, and meeting with the architects of the solution.

Once the architecture diagrams are created, it’s wise to check the gathered information with what actually happens in the solution, by doing some runtime inspection, also called application footprinting (this is where debuggers and external tools come in) which is intended to identify how the application receives input from the environment.

At this point, you should have enumerated all the application’s entry points, noting for each one of them if it’s remote, encrypted, which protocol is using, which interface type it has, and if the interface has authentication and session management, etc.

Next Steps

On my next posts I’ll be describing the process of threat modeling per se, and the usage of Microsoft SDL Threat Modeling Tool.

Hope you find this information useful; feedback and comments are always welcomed !

You can find some useful resources below.

External Data Flows

• Networks I/O
• File I/O
• Registry
• Named pipes, shared memory, any OS object.
• Windows messages
• Others…

Useful Tools for Application Footprinting

• Sysinternals – Process Explorer
• Sysinternals – TCP View
• Sysinternals – Process Monitor
• Wireshark

Related Links

• http://msdn.microsoft.com/security/securecode/threatmodeling/acetm/
• http://msdn.microsoft.com/en-us/library/ms998408.aspx

Recommended Reads

• The Art of Software Security Testing
• Threat Modeling (Microsoft Professional)

Although I was already familiar to the Test-Driven Development (TDD from now on)paradigm, today I finished reading Kent Beck’s Test-Driven Development: By Example and found some useful tips and ideas I would like to point out.

Before starting there’s an advise I would like to give, and is what I always try to remember when writing a test or even code. This is that tests are part of the Code Documentation. It is very important to have this into account when coding and testing, for it is important that others can understand what are you testing, what should they expect as the result, and how you’re testing it.

Simple step-by-step Sum-Up

Taking Kent’s rules and set of steps, and by adding some of my own, I created this diagram. I find very useful when it comes to remembering TDD’s basic ideas.

The To-Do List

It’s very important the use of a To-Do list, in which we should add all the things that we realize must be done in other to completely test/implement all what needs to be done.

For example, imagine we are writing an Equals test for a recipe.

          [TestMethod]

          public void TestEquals()

          {

               Assert.AreEqual(new Recipe(1), new Recipe(1));

               Assert.AreNotEqual(new Recipe(2), new Recipe(1));

          }

Recipe’s constructor receives the ID and two recipes are the same if their ID is the same.

Now we implement the Equals method. In order not to extend myself too much, I will cut some step off of TDD.

           public override bool Equals(object obj)

           {

               return this.Id == ((Recipe)obj).Id;

           }

As you can see, I’m not checking if the object is null, neither if it is actually a Recipe I’m comparing “myself” to. This doesn’t matter right now, but as I realize what I’m missing, I should add it to my To-Do List, and come back to it later. Remember this is just an example, I’m not sure I’ll do this in separate steps to be honest.

Isolation

It’s desired that every test is absolutely isolated from the rest, this is, the failure or success of a test shouldn’t affect in any way the following tests result. In order to do this, some good tips are:

• Separate tests in classes. It’s  not necessary to have one test class for each real class, but yes to have well organized set of tests so that everyone who reads it understand (as I stated before) what you’re testing, and what should they expect as a result.

• Separate tests in methods.  It  is  very  important  that tests keep small and simple. To achieve this is a good practice to separate the different tests in different methods. It’s also useful using clear test methods names.

• Not caring that much  of  Performance.  This  is  a  personal  tip,  and  goes against my “programming philosophy”. Sometimes is better to have duplication when creating tests, in order to assure the isolation, than having a very efficient code without any duplication, taking the risk of breaking the isolation.

Test Sections.

I was going to state this as good practices, but giving it a second though I realized its a bit more than a “good practice”.

Even inside a test method, I like to order the code pieces into three different states:

• Declaration and instantiation:  We declare and instantiate all the object that are to be used for testing.

• Work: We work with the objects. I couldn’t find a better way to explain this, in other words, what we do is what the test is supposed to be testing.

• Assert: We  assert  the  actual  data  against  the  expected  one  in  order to determine if the test succeeded or failed.

Good practices

This are some good practices I could retrieve from the book and from my personal experience. I believe in constant learning, so I won’t call this practices “Final”, but I think they’re a good starting point.

• Try to start writing the Asserts First. By doing this you’ll have a clear view of which the result should be.

• Make the Actual and Expected Data evident  for any outsider that is  reading the tests.

• When working alone, leave the last test broken.  By  doing  this, when you go back to work the next day, you have a starting point.

There’s much more to be said about TDD, but I wanted to give a quick-pick of the paradigm, I’ll go deeper into it in further posts.

This last habit encourages us to focus on ourselves and take time to "sharpen the saw" this is, renewing in four dimensions, in a balanced way:

• Physical: The physical renewal is basically to care effectively for our physical body and all that it involves (eating, exercising, resting, etc.), it is highly related to habit 1.
• Spiritual: The spiritual renewal provides leadership to our life, It’s highly related to habit 2, and our commitment to our value system.
• Mental: The mental renewal is to keep "training" the mind. In order to  do this, Stephen advices us to study, read, explore new subjects (outside our action fields), write (thoughts, experiences, insights or learnings). He also advises us against watching television (and I would add using Internet) in a non-discriminative way (without discriminating the information we receive). This renewal is highly related to habit 2 and habit 3.
• Social/Emotional:  The social (or emotional) renewal  it’s basically achieving interpersonal leadership, empathic communication and creative cooperation. Being careful of what we reflect to others about themselves, for it may influence them in a negative way, is a way of renewing in this dimension. It’s highly related to the Public Victory.

Renewal, as Stephen describes, is the process of renewing all the six other habits. Seeking Private Victory in a daily basis, is the foundation for the Public Victory, and renewing the habits (working on them) at least an hour a day, leads to Private Victory.

Final Conclusion

The book gives an interesting and (in my opinion) very accurate description of how a highly effective people should be, for it not only focuses on independent achievements, but also on interdependent ones.

In my previous posts I stated my opinion and a brief summary of what the writer describes in each habit, so I won’t go over that again. The one thing I would add is a final concept about the book.

The Seven Habits of Highly Effective People is a very interesting and recommended reading, for it makes you retrospect to what you have done in life, analyze yourself, and learn to see every situation from a different point of view.

Another interesting point of the book, even though it gives you "application suggestions", is that it can be read not only as a recipe you could follow, but also in the way that it would help you most (general guidance, other point of view about life, recipe, etc.).

The third part of Stephen’s book, is about the public victory, and it introduces us to habits, 4 (Think Win-Win), 5 (Seek First to Understand, Then to be Understood), and 6 (Synergize). I find these three habits more interrelated than the first three (private victory), that’s why I’ve decided to write of all of them on a single post.

Fourth Habit: Think Win-Win

The first of the three is to Think Win-Win, it tells us to seek our winning without a competitive approach, this means, not to seek our winning in other’s lost. It is highly related (in my opinion) with the sixth habit (Synergize), and with trust. This is to say, without trust you cannot delegate (in a Stewardship way, as stated in the third habit), you cannot think of a win-win situation, for you don’t trust in your winning in terms of other’s winning, you cannot even understand the other’s needs, for you focus on yourself, and on your point of view. Moreover, without a synergetic paradigm you don’t think that the whole is stronger and more efficient than its parts, but we’ll get to this later on this post.

Stephen introduces us the concept of "Emotional Bank Account", this means, those little positive (deposits) or negative (extractions) things that we do, and end up being the trustworthy parameter of ourselves. I agree with him on this concept, I know our actions make us who we are, at least, through third-party eyes. But I think no one should have this knowledge, I mean, no one should do things thinking in this "Emotional Bank Account", for it wouldn’t be a sincere action, but an interested one (not being in accordance with the first three habits).

Fifth Habit: Seek First to Understand, Then to be Understood

The second habit (fifth of the hole) is to Seek First to Understand, then to be Understood. The writer advices us to learn to listen in what he calls an "empathic listening". The basic idea of this concept is to truly understand what the other person is trying to say, what does he/she really means, what he/she is feeling, and not just what he/she is literally saying. By doing this, we gain trust, and we achieve an "Emotional Bank Account" deposit, which allows us to be heard and eventually understood or taken into account when we advice (in a customized way). Once we achieve "to Understand", we need to seek "to be Understood" this is the second half of the habit.

Sixth Habit: Synergize

The last habit of the "Public Victory" is to Synergize. In this chapter, Stephen basically advices us to be synergic in every aspect of our lives. This habit requires the previous five in order to be achieved.

The definition of synergy is that the whole is greater than the sum of its parts. This applies in every aspect of life. Synergistic communication allows us to be open to new ideas or points of views. I felt particularly identified with "Valuing the Difference", a part of the habit in which the writer tells us to value each disagreement we have with people, for it’s the best way of understanding and, eventually, learning. I felt identified because it’s kind of my philosophy of life. "I want to understand" "I value that difference".

Conclusion

I think that it’s very important to have these three habits into account in everything we do in life for they are an important basis for human interrelations. I would advice to read this third part of the book to those self-centered or those who sometimes fall in the thought that personal victory is only achievable defeating others.

The third habit, Put First Thing First  of Stephen’s book introduces us a Time Management Matrix, where he defines the activities into Urgent/Not Urgent and Important/Unimportant.

He encourages us to work on those activities on Quadrant II for they are Important, but not Urgent, this means, they allow us to plan, and manage the way we deal with them. Focusing on this Quadrant ends up in an efficient management of our time.

In order to do this, he introduces us with what he calls "quadrant II tool", a fourth generation time managing tool with six properties (Coherence, Balance, Quadrant II Focus, "People" Dimension, Flexibility and Portability).

In my opinion this is a good way of managing time and priorities, for it allows you to focus only on those important things (who likes to waste time on unimportant things?) and to achieve a high level of efficiency with the proper planning and dedication to those activities.

Focusing on Quadrant I, as Stephen says (and I agree), makes you work and live constant-crisis life, which keeps getting bigger, until it turns over you and your life. It’s impossible not to deal with urgent and important situations, but we need to work on the not urgent ones on order to, slowly, reduce the urgent and important ones.

Delegation

The writer ends up the chapter with useful information about Delegation (or, at least, useful for me), introducing the Gofer and Stewardship models of it.

Gofer delegation is based on a vertical authority and on a one-on-one supervision of the methods applied to work through or solve the delegated issue. On the other hand, Stewardship delegation is based on a more trust-based paradigm, in which the person who delegates, sets the desired results, guidelines, available resources, reporting and evaluation methods, and specify the consequences of both bad and good results. This method is focused on results instead of methods.

Once again I will recommend this chapter for those non-methodic and non-principle-centered persons who tend to loose focus when critical situations occur, or waste much time on not important activities.

The second Habit, Begin with the End in Mind tells us to know where we are heading, to set our final goal or destination before we start anything; it advise us to “create” ourselves  in a principle-centered way first (which I agree with) and once we’ve done that, set our final goal in life, and work with it in mind every day.

I have a personal opinion about this, and it doesn’t differ much with Stephen’s. I believe it is important to have a final goal, but I work with smaller everyday goals in order to achieve this final one. The truth is, I don’t think this last one is achievable, but more like an engine that keeps us running every day, those achievable are the smaller ones, that are quantitative and measurable (you can actually say, “I achieve this goal, what’s next?”. I won’t go to deep within this idea, for is not the purpose of this post, but that’s the big picture about it.

Further in the chapter, the writer gives us a “quick pic” into different non principle-centered ways of life (Spouse, Family, Money, Work, Possession, Friend, Enemy, Church and Self -Centered), based on what he calls the “four life-support factors” (Security, Guidance, Wisdom and Power).

I didn’t found it a very complex or revealing chapter, because it’s what I usually do (Begin with the End in Mind, set goals, identify roles…). So it was more like a “you’re not doing it so wrong” chapter for me.

I would recommend this chapter for non-organized people, or those who don’t are principle-centered, because it gives you a different point of view about lifestyle and priorities.

I finished reading the first habit: Be Proactive, of “The Seven Habits of Highly Effective People” book, by Stephen R. Covey. And it got me thinking about myself…

Am I Proactive or Reactive? Do I Focus on my Circle of Concern or on my Circle of Influence? Have I successfully categorized the problems I faced, and focused on those which I have Direct or Indirect control? Do I make and keep commitments? Am I part of the problem or the solution?

I took some time to think about all this, and realized I was a “theoretically proactive person” but, in many circumstances of life, I find myself having reactive responses.

I am a preacher of proactive philosophy, I am always advising to focus on the Circle of Influence (maybe I called it differently, but it’s the same idea), to learn how to live with those problems we can do nothing about, and try to face and solve those involving our own behavior or other people’s.

I am the first one to defend the idea that “anything can be done” and if you can’t it’s only because you don’t “really want to” (of course I don’t mean physically impossible things, or illegal activities, even though you could actually do this last ones, accepting the consequences).

I am even an initiative person, I am not expecting for circumstances to “magically appear”, I plan my path through life committing myself, setting goals and working to achieve them; I deal with unexpected turnovers, knowing that I’m responsible for what I do.

I am always open to opportunities and take them if I feel they will lead me to my final destination.

But, there come days, even weeks when I fall in the reactive pattern and think that everything surrounding me is the cause for me not achieving my goal or, at least, not achieving it on time.

So, am I a proactive person?

I guess I can’t affirm that yet, but I think I am on the right tracks to being one.

I believe in people’s permanent learning and constant evolution, and I realize this reading made me understand and learn about myself in a different and clearer way.

It’s very important to know where you’re standing, not only outwardly but also inwardly. And I think this book, at least this chapter (and the introduction), helps you take an inside look of yourself and learn to be more “Effective”, to understand who you are.

I would strongly recommend this reading for anyone trying to be more effective in anything that he or she does in life.

Chapter 1: Backdrops: The science of Scrum

In my first day at work, I’ve been given this chapter of Microsoft’s Agile Project Management with Scrum to read, and understand Southwork’s working method. I won’t do a summary of the chapter, for the chapter itself is a summary of Scrum, in this post, I will try to identify and explain in a very simple way, the basis of Scrum.

I will start by introducing some concepts that will help you to understand Scrum, then, explain Scrum Flow, to end up with the Scrum Artifacts mentioned in the book.

Empirical process control is when a regular building process is divided into complex activities that must be fulfilled, and controlled in order to achieve an acceptable quality level. This process is vital when the complexity of intermediate activities (during a building process) is too much for a defined process control.

Implementation of empirical process control, requirements:

• Visibility: the aspects that affect the outcome of the process must be visible for those controlling it.
• Inspection: the aspects of the process must be inspected frequently enough for detecting unacceptable variances in it. The capability of the inspector is crucial for the correct inspection.
• Adaptation: If the result of the inspection is of unacceptable variances, the inspector must adjust the process or material being processed, in order to get an acceptable final product. The adjustment must be made as quickly as possible, to minimize further deviation.

Complexity in three different dimensions: In software development, complexity is present in three different dimensions,

• Requirements, it’s common that there are many customers who have different needs. It’s also common that these needs change through time, or are ambiguous, or difficult to represent in software.
• Technology, complex frameworks, complex business problems solutions, when put together are far more complex.
• People, interaction and teamwork adds another form of complexity.

Incremental Iterative process:

• Daily iteration (24hour inspection), team members meet to inspect each others’ activities and make appropriate adaptations.
• Sprint, results in an increment of product functionality (potentially shippable). Constitutes the empirical inspection and adaptation practices of Scrum.

Scrum Roles:

• Product Owner, Defines Requirements (Prioritized Product Backlog), return of Investment objectives, release plans.
• Team, Develop functionality in terms of the Product Backlog, it’s self-managed, self-organized and cross-functional.
• Scrum Master, In charge of teaching and ensuring that everyone follows scrum practices.

Scrum Flow:

Sprint 

1. Product Owner Presents the highest priority Product Backlog to the team, the team commits to what it believes can turn into an increment of functionality by the end of the sprint.
2. The team plans out the sprint (Sprint Backlog).

WORK-Iteration (daily) → creative process→ heart of scrum

Stand-up: Every day the team gets together and answers:

• What have you done since the last Daily Scrum meeting?
• What do you plan on doing until next Daily Scrum meeting?
• What impediments stand in the way of you meeting your commitments?

At the end of the sprint, the team presents the increment of functionality built, so that the Product Owner and stakeholders (those interested in the software) can inspect it.

Scrum Process Overview,

from Agile Project Management with Scrum, By Ken Schwaber

I’ve copied this image form the book, because, for me, was the easiest way of understanding Scrum’s hole picture. 

The chapter ends with an explanation of the Scrum Artifacts (Product Backlog, Sprint Backlog); these are table charts in which Scrum defines the work, or tasks that are meant to be made. Setting the estimated time required for each task and its priority.