גאווה ודעה קדומה

First Impressions from TechReady7 (Seattle, WA)

Hello from chilly Seattle,

Yes, chilly, as in “a bit cold”. I talked with my wife earlier and she told me how hot it is right now in Israel while I’m wearing a coat over here (which I had to buy upon arrival since usually the weather here is just fine in July and I didn’t think about bringing anything warm…).

So, most of Israel MCS (12 people!) are here in Seattle for the week and beside excessive meat and alcohol consumption we’re learning quite a few new things!

TechReady is a pretty big internal event for technical Microsoft FTEs (Full Time Employees). It happens twice a year in Seattle, WA. The main advantages of this event are:

1.       All of the presenters are members of the different product teams. Most of them are members of the dev teams.

2.       The scale is huge (5 days, ~7000 attendees, ~1200 sessions, hundreds of hands-on-labs).

3.       Great networking opportunities – both with peers from other countries and the dev teams. This is how we maintain our great relationships with the dev teams and leverage these relationships for the benefit of our customers.

4.       The nature of the content is “unfiltered”. We get the essence of the content directly from the source – good, bad and ugly.

5.       It’s fun :-). On top of the party, the networking, the pubs, the live shows (Seattle, the cradle of Grunge still maintains its coolness!) there’s the gaming night. Playing Halo against a few hundreds of people in a huge hall is quite an experience…

Up until now, I had the pleasure of attending some very interesting sessions delivered by Ray Ozzie, David Chappell and many others. We get technical updates and interesting overviews on various current and future trends, technologies, architecture concepts and methodologies.

For me, personally, the most interesting subjects presented until now were around our Application Platform roadmap, Software + Services concepts, Agile implementation in P&P, Virtualization vision and strategy, Enterprise Library 4.0 and Composite WPF.

We still have 3 days to go and the amount of content is overwhelming. I still hope to learn more about Office 14, VSTS futures, SQL Server 2008, Windows 7, more S+S (this is The next big thing). I have at least 3 sessions scheduled for each time slot and choosing which one I should go to every time is pretty hard…

Over the next few days expect to see more posts from my peers laying out their insights and perspectives on the content we’re absorbing over here. Almost all of what we learn here is still confidential (sorry for not sharing L) and will be publically revealed only around PDC but still there’s a lot we can already talk about now. And we will…

חינם - רשימת כלים חיוניים חופשיים לזיהוי בעיות ביצועים באפליקציות

סיפור לקוח – שיפור ביצועים מערכת מידע ברמת ארכיטקטורה

 

eXtreme Waterfall Programming (subtitle: “what it takes to make waterfall work”)

My MCS Israel colleague Memy Lavi can always be counted on for interesting content, ideas and anecdotes.

A while back he sent me an article titled "They Write the Right Stuff" by Charles Fishman, and after reading the article I found that I just could not stop thinking about what it meant.

Let's start with a short description:

The article describes the processes and development methodologies of NASA's on-board shuttle software, developed by 260 women and men of the Lockheed Martin Corps space mission systems division.

The information in the article is fascinating:

• A bug-to-LOC (lines of code) ratio that is incredibly low, especially when considering the complexity of the software they write and the scenarios in which they perform.
• Continual improvement in error rate (they produced "world class" software ten years ago and since then they achieved a 90% percent improvement in code quality).
• A predictable (on-time and on-budget) development process, that enables a sustainable delivery velocity and a healthy work-life-balance.

How do they do that?

Well, according to my interpretation of the article, it's an achievement that is possible by implementing an extreme form of waterfall methodology. A methodology I would argue deserves the (tongue-in-cheek) title "eXtreme Waterfall Programming".

Everything – really, EVERYTHING – is planned, designed, defined in advance. The current 400,000 LOC in the software are written according to a 40,000 page specification document (actually – it's not "a document"… its 30 volumes of specs).

Read that again: This is 1 specification page per 10 lines of code!

And in order to bring all those lines of pseudo-code specifications to life, you need to have order. Discipline. Rigidity. The programmer must comply with the specs absolutely and totally. How extreme is this compliance? Here's a quote for you:

"…the culture is equally intolerant of creativity… You have to do exactly what the manual says, and you've got someone looking over your shoulder… the process does stifle creativity".

And what does it mean to change the code?

"…no coder changes a single line of code without specs carefully outlining the change".

For example, one change of 1.5% of the software, 6,366 LOC, was approved after 2,500 pages of specifications were written.

You can imagine the cost of such a process. And you can just as easily imagine why it's worth it. The Arriane 5 rocket exploded because a programmer did not check for a buffer overflow; the Mars Global Surveyor crashed because one team calculated in meters, while the other team calculated in yards; developing software for space is definitely one of the most bug-intolerant jobs you can get as a programmer…

OK, that's interesting. But why should I care?

I've spent quite a few years of my life as a project manager and a solution architect of projects that were waterfallish.

And it didn't work.

I am not saying that the projects failed miserably. On the contrary - most were quite successful, eventually J.

The problem lies elsewhere. The requirements were always either (1) ill-defined (2) fluid (3) ultimately ignored.

Unlike the requirements in the space industry, where requirements can be frozen in time, software conservativeness is a virtue and creativity is not tolerated, the IT world in which I live professionally is always in flux, standing still leads to the business free-falling and programmer creativity is a pre-requisite.

Trying to impose a waterfall approach on an IT project, inevitably led to an unhappy customer trying desperately to change the specs halfway through the development phase, or to a development team trying to imaginatively fill the holes in a specs document that proved to be half-baked when it came to actual implementation.

There's nothing new here, and software methodologists, and especially Agile evangelists, have been pointing out these waterfall deficiencies for years.

However, I do not think that the problem is in the waterfall approach itself. I would argue that it is a feasible development process given the appropriate circumstances and resources, and it seems to me that both can be found in the example of the on-board shuttle software group.

The problem is that once you start diluting the methodology (introducing frequent changes to the specs; limiting the tremendous effort required to write and maintain specs that are detailed enough; not supporting the development process with the resources required – reaching up to 30 minutes per line of code) this dilution will bring your project down.

The same methodology dilution can be expected to cripple an Agile development process as well. See what happens when you take an Agile team, and make it relinquish unit tests (or TDD), avoid pair-programming, delay integration tests and space-out your iterations. Have fun. Agile, like Waterfall (actually more so), is a balanced methodology. It can quite easily be unbalanced.

And that's why I like the story of the on-board shuttle software group so much. It is the first case study of a waterfall methodology that actually makes sense to me. It takes a whole lot to make it work – but it works. And the cost is tremendous.

The only question remaining for each IT software project that tries to make it the waterfall way, is whether it knows what it takes to make it the waterfall way, and whether it is willing and able commit to it, without diluting the process - or by doing so, crippling the process and the project.

It looks like it, It feels like it but it is not It – Phishing for Dummies

Phishing is a new hacking technique which opened a new era of hacks. I call it a new era due to the fact that once again changed the level of hacks. It caused the boundary between application layer attacks and social engineering to be nebulous. We all have heard that security should be deployed and considered in layers. Have we ever thought about all the layers? Is social engineering was ever taken into consideration?

We have heard thousands of times that tools and hacking techiques are getting more and more sophisticated and so are the defense mechanisms, did we ever considered the homo sapiens should be taken into this equation as well (both as an attacker and as the victim)?

Well the attackers have alreay started ...

Security hacks started in telephony, then moved on to network attacks, then came the era of application security which we thought is the worst and considered to be the last one. We considered it as layer 7 (the highest OSI model layer) attack. However, recently we are facing a new challenge: social engineering security. To be honest it was always there, we all knew about it and we were all aware about the human affect on security. At the end it comes to human beings, however the main question here is can technology overcome human being’s mistakes?

Phishing in a Nutshell?
Phishing is a social engineering technique that is used by hackers\attackers in order to capture a naïve user’s login information (username and passwords) to different web sites (i.e. banks, credit cards, Paypal and others). These credentials are then used in order to steal money or information from those accounts.


IRS phishing example

How to Phish?

The Phishhook
When I was a child I always wanted all my clothes and shoes to be Nike. Where I lived there was a very common company for clothing including shoes named Mike. Guess what, their logo was the same as Nike’s with small change replacing the N with the M. My mother paid half the price and was happy. By the way two weeks later all my friends were having the same clothes and we were all Mike’s best friends.

Well Phishing is just the same imitating the attacked web site. Let say there is a bank named ibank.com its logo starts with capital “i”, when you write its name it looks like Ibank.com when you write it with lowercase “L” it looks like lbank.com. I am sure you all agree with me that only the minority of the population would notice the difference, isn’t that so?

Of course the domain name is not enough in order to convince a customer that he got to the website he was looking for. The main trick here is the look and feel (in advanced techniques the domain name is not an issue at all).
So now the hacker’s challenge is to dress his web site with the same clothes as the attacked web site – meaning building his trap in a convincing way so the naïve user would not even doubt that this is not the original web site. This is an easy task; one could even use the same pictures, same images as well as same colors. It might even be easier if he gets to the original web site download its HTMLs (the Web pages) and change it just a bit in order to put the attackers functionality (As for the functionality we’ll discuss it a little later) but keeping the look and feel of the original ibank web site.


The Bait
All the attacker is left with now is to convince customers to surf and visit his website. There are different ways to do that, he might spread an email or might post a message into a banking forums or even send IM messages to people. The message will be the bait and will contain two main components: 1. Offerings - to attract the fish to eat the bait (pressing the link)
2. Link – the bait itself (pressing this would lead the user to the hacker web site)
Therefore the message (email, IM) would contain some attractive offerings that will cause the naïve user to press the attached link such as an offer to customers to open a checking account with very good interest. In that same message he will add the link to the bank’s site (of course the link would lead to the attacker’s web site). Once the user clicks the link it feels like he got to the real banks web site. He tries to log in in order to get the new deal he got and he supplies its credentials (I hooked a fish).


After the Bait was Hooked
Here the attacker has two functionality options:
1. Grab these credentials and store it in its DB then displaying a message the bank web site is not available try again later.
2. Grab the credentials and redirect the client to the original website and running the client under the real login process so the customer won’t even know he was redirected.

The example given above is not theoretical and there are lots of “flavors” and permutations for Phishing.

Ebay Phishing Scam

How can we Make the Phisher Starve

The main problem though is how can we solve or overcome such challenges? And what is it different then old hacking techniques.

The main difference is that old hacks were using the human mistakes (bugs) in order to penetrate the corporate network or applications. The hackers used those holes in order to gain unauthorized access to data. As a result we could have put the blame on the organizations functionaries such as developers, system administrators, QA personnel, security stuff and others – it was someone’s responsibility to make sure these kinds of hacks would be found and fixed. Whereas the new attack is out of the organization hands and responsibility, even if the web site is totally secured and all the countermeasures were put in place and the web site is using all security mechanisms such as authentication, authorization, encryption, and many others all these won’t do anything to prevent from someone developing a masquerading website and attract users to get there and then stealing their identity.

There are a lot of groups and products that claim they could protect from these kinds of attacks but none take high percentage of responsibility for that. I believe, then, that the only tool we have to prevent these attacks is by education and awareness both to the organizations and customers. Once again back to my childhood when mother kept telling me “don’t open the door to strangers”.

Guilad Regev
ACE Team

מי משתכשך בבריכת החוטים?

BI End-To-End Solutions - The MS BI Roadmap By Microsoft Enterprise Cube (MEC)

Hi Everyone,

Today I want to share with you the next generation of BI Solutions - Microsoft Enterprise Cube (Project name MEC).

What Is Microsoft Enterprise Cube?

Microsoft Enterprise Cube is designed to provide industry verticals with real-time, end-to-end performance management analytical solutions that target the client’s pain-points and provide a low cost of implementation, quick time to production with a rapid return-on-investment. These solutions are comprised of the Microsoft BI product stack (SQL, PPS, MOSS) and include content around vertical industry business pain points such as standards and best-practices based data models, predictive analytical models, KPI's, reports and workflow.

Solution Components

The Enterprise Cube solution supports four BI/Business Performance Management modules, which are:

• Customer Segmentation - provides insight into customers and enables service providers to increase marketing efficiencies by identifying customer segments and expected buying behavior.
• Profitability Management - identifies and analyzes customer accounts by most and least profitable. Embeds workflow's that provide a recommended course of action based on call patterns.
• Revenue Management - ensures that service providers’ processes, practices and procedures maximize revenues by identifying any leakage areas and concerns. Plans actions and views trends to help increase revenue.
• Churn Management - identifies, reduces and prevents voluntary customer attrition through proactive and reactive measures.

MEC is a BI framework designed to make the promise of true enterprise Business Intelligence solutions a reality. By incorporating industry and BI/BPM best practices, Microsoft Enterprise Cube delivers true people-ready BI & BMP solution to our customers.

MEC is built on top of Microsoft BI stack (SQL Server, PerformancePoint Server, SharePoint, etc) and a series of point-solutions.

Microsoft BI stack

What vertical industry solutions are planned for MEC?

• Communications Sector
• Retail
• Manufacturing
• Healthcare

MEC Models Architecture

Watch Microsoft Enterprise Cube Video

Visit Microsoft Services Web Site at www.microsoft.com/services

Bye

איך להפוך לארכיטקט?