Friday, December 21, 2012

Implementing SCRUM – Workshop

Implementing SCRUM – Workshop  


About SCRUM

SCRUM appears simple, yet has practices that deeply influence the work experience and that capture key adaptive and agile qualities. Scrum’s distinctive emphasis among the methods is it’s strong promotion of self directed teams, daily team measurement and avoidance of prescriptive processes. SCRUM practices are founded on the Agile principles (see annexure). Some of the key agile practices include;

·         Self directed and self organizing teams
·         No external addition of work to an iteration, once chosen
·         Daily stand up meetings, with special questions
·         30 calendar day iterations
·         Demo to external stakeholders at the end of each iteration
·         For each iteration, client-driven, adaptive planning


The SCRUM process overview













Scrum hangs all of it's practices on an iterative, incremental process skeleton. Scrum's skeleton is shown in the diagram above. The lower circle represents an iteration of development activities that occur, one after another. The output of each iteration is an increment of the product. The upper circle represents the daily inspection that occurs during the iteration, in which the individual team members meet to inspect each other's activities and make appropriate adaptations. Driving the iteration is a list of requirements. This cycle repeats until the project is no longer funded.

The skeleton operates this way: At the start of an iteration, the team reviews what it must do. It then selects what it believes it can turn into an increment of potentially shippable functionality by the end of the iteration. The team is then left alone to make it's best effort for the rest of the iteration. At the end of the iteration, the team presents the increment of functionality it built so that the stakeholders can inspect the functionality and timely adaptations to the project can be made.

Some Organizations using SCRUM

Microsoft, Sun, Sammy Studios, Siemens, Philips, BBC, IBM, SAIC, Ariba, Federal Reserve Bank, HP, Medtronics, Motorola, Valtech, IDX, Primavera, Yahoo, Conchango, Bentley systems, CapitalOne, Federal reserve bank, Clear channel, Xerox, Nokia, Novell

The business case

Organizations using SCRUM methodology have reported productivity gains to the tune of 50% to 100% (on the very conservative side)


The key SCRUM glossary 

Product backlog
All features of the product
Release backlog
A subset of the product backlog, targeted at the next production quality release
Sprint backlog
Tasks for the iteration. Granularity 4-16 hours
Sprint
Iteration of 30 days duration
Daily scrum meeting
Daily stand up meetings
Team introspections
Reflect and improve upon the learnings
The product owner
The product owner is responsible for representing the interests of every one with a stake in the project and it's resulting system.
Teams
The team is responsible for developing functionality
Scrum Master
The Scrum Master is responsible for the scrum process, for teaching scrm to everyone involved in the project, for implementing scrum so that it fits within an organization's culture and still deliver the expected benefits, and for ensuring that every one follows scrum rules and practices
Scrum has defining moments when the concept of a self-organizing team becomes clear.
Scrum and other agile processes have several defining moments when a key participant really "gets it." When these occur, I know that everything is going well and that the expected benefits will result. These flashes of insight include:

  1. The customer realizes that it's OK to proceed without all of the requirements being defined.
  1. The customer sees a product increment demonstrated at the end of each of the several sprints. He realizes that his involvement was important and had an immediate, tangible result. He also realizes that the project will be successful and deliver something he wants and needs.
  1. A team member trusts that someone will help when problems occur. After identifying an impediment or problem during a daily Scrum, either the Scrum Master or a fellow team member provides immediate help.
  1. The IT manager senses teamwork in progress after walking through an open area where scrumming is taking place. The buzz, energy and focus are palpable.
  1. The project manager realizes that she doesn't have to police the staff.
  1. The team realizes that no one is going to tell them what to do.
  1. We presented agile concepts and overviewed Scrum and XP.
  1. The customer described the business domain.
  1. We explained the product backlog, sprint planning and sprints concepts.
  1. The team members introduced themselves.
  1. The customer and team defined a product backlog (a prioritized requirements list) with enough work to drive the team for several months of sprints.
  1. The customer and team brainstormed about how much functionality the team could build in the next sprint.
  1. The team defined the sprint backlog (their collective tasks) for the next sprint to turn the selected product backlog into working functionality.
  1. We presented daily Scrum, end of sprint, sprint signature and management topics.
  1. We explained XP practices and described how they work with Scrum.
  1. The project team began the first sprint.




Experiencing Agile  -  Please Read annexure A and B






Our Methodology of implementing SCRUM

The main goal of this program is to ensure effective implementation of the SCRUM methodology, resulting in business advantages.

Since SCRUM is not highly prescriptive, reading and class room training alone will not help for it's effective implementation.  The model we propose, include a two day workshop and 10 days on site support of a Certifed Scrum Master, who will work along with the teams, in implementing SCRUM.

Phase – 1  - Duration 1 day

Session -1 Understanding the SCRUM framework


1.     Adaptive Vs Predictive
2.     When to go agile
3.     Agile manifesto
4.     Key Agile principles
5.     Key agile methodologies overview
6.     Key  SCRUM practices awareness

a)     Product backlog
b)    Release backlog
c)     Wide band Delphi – estimation
d)    Sprint planning & sprint backlogs
e)     Backlog graph
f)     Roles and responsibilities
g)    Daily stand up meetings
h)      Team introspection


     Session -2  - Experiencing SCRUM   - Case study based exercises

1.     Sprint planning meeting  
2.     User stories and story points
3.     Estimate using wide band Delphi
4.     Triangulation
5.     Requirements prioritization
6.     Release planning
7.     Sprint planning
8.     Burn down chart
9.     Stand up meetings
10.  Team self organization based on imposed constraints


Phase – 2

Session-3 – Follow up program (duration 1 day, 30 days after session 2)

The focus of this session is to facilitate right implementation of scrum. This is optional and at the same time, highly recommended if the organization is implementing scrum. All the participants should have attended sessions 1 and 2, and should have at least one SPRINT experience. 

1)      Scrum implementation assessment
2)      Retrospective meeting for the real life scrum implementation done by the participants
3)      Action planning


Professional service charges

For phase 1                               -   Rs. -

For phase 2                               -   Rs. - 



This proposal is valid for a period of one month, from the date of submission

All taxes will be extra

50% of the professional service charges to be given on day one of the assignment

Return flight ticket from Cochin / Bangalore to the location, stay in a decent hotel and Local conveyance extra, for each trip made. Two trips are required if the customer is going for Phase1 and Phase 2.

The program will be delivered at the customer’s place

The participants will be provided with reference material a copy of the slides used during the workshop

All the participants should have at least one project lifecycle experience

We recommend a minimum of 8 participants and a maximum of 20 participants / batch.


















Annexure – A

The Agile Principles

1.     Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2.     Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage.
3.     Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
4.     Business people and developers must work together daily throughout the project.
5.     Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6.     The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7.     Working software is the primary measure of progress.
8.     Agile processes promote sustainable development.
9.     The sponsors, developers and users should be able to maintain a constant pace indefinitely.
10.  Continuous attention to technical excellence and good design enhances agility.
11.  Simplicity – the art of maximizing the amount of work not done- is essential
12.  The best architectures, requirements and designs emerge from self organizing teams.
13.  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behavior accordingly.


















Annexure – B  
Agile Epiphanies

In my experience with agile methods, I've found that hands-on practice quickly leads to cries of "Eureka!"
Some quick definitions are in order:
·         The Scrum Master is a coach who ensures that agile practices are used correctly.
·         The Build Master is a senior engineer who watches for good engineering practices and successful, continuous builds.
·         The Sprint is a 30-day work period that produces an increment of product functionality.
·         The Daily Scrum is a stand-up meeting in which status reports are exchanged, progress is observed, and impediments noted and removed.
·         The Customer is the person paying the bills.
·         The Product Backlog is an emerging, prioritized list of customer requirements.
·         The Sprint Backlog is a list of tasks that the team completes to turn a requirement on the product backlog into a product increment during a sprint.
Getting It

These moments are mini-epiphanies, that flash that occurs when people suddenly understand their roles and how they relate to those of their colleagues. 
I was particularly interested in the fifth epiphany (the project manager understanding his or her new role) and how this realization depends on the sixth epiphany (the team self-organizing and figuring out its work). No matter how many books you read or presentations you attend, these personal insights can arise only from real-life experience.





















Finding the Agile "Feel"  - Experience sharing
You can describe how to ride a bike to someone, but he won't really "get it" until he experiences firsthand how to balance while pedaling in motion. Agile processes feel different, and teams need to get that feel—close-up and personal.
The project managers were reluctant to get started, preferring to prolong the discussion. Although they were interested in agile processes, their real-world projects were important and ongoing.
Entering the workshops I used to initiate the projects, these managers were skeptical. They were used to starting projects by doing more, and were now feeling adrift without the detail work they expected to precede the development of a plan. To make matters worse, the project teams were new to the project managers on the XYZ projects—the teams largely consisted of outside contractors.
The workshop flow was:
The project managers for the last two projects turned around at step 6, when the team defines the work for the next sprint. At that moment, they felt as though a burden had been lifted from their shoulders. We started step 6 by reviewing the selected backlog—what the team is thinking about turning into coded, working functionality by the end of the next sprint. We then asked the team to spend the next four hours figuring out how they were going to create this working functionality, including a rough design and the work tasks. Then, we yielded the floor—no one could talk except the team members.
At first there was an uncomfortable silence. The team members were thinking, "We're in a training session—they'll tell us what to do next!" But we didn't. Soon, the pressure of the silence spurred members to offer some initial observations and questions. This quickly escalated, because software developers are usually very opinionated and have lots of ideas. In the normal, top-down project management process, however, they aren't usually asked; they're told! Here, the responsibility of filling the silence served to nudge team members into independent thinking.
The team brainstormed, plotted, schemed and even planned how it would build the code during the sprint. The conversations started slowly, but soon people were working on whiteboards, drawing designs and noodling out the functionality. As the team dialogue progressed, the ScrumMaster wrote down the tasks under discussion. At critical points, the customer or project manager offered observations, made decisions and helped the team focus on the work. We began to recognize the familiar agile "buzz" that indicates that the participants "get it."
After four hours, we called a time-out. The teams had defined their work for the next sprint as well as possible. Some unknowns would have to be worked out, some of the estimates were vague and new work would appear, but the team had gotten a feel for what it would do in the next 30 days.
As the team planned and brainstormed, a light bulb switched on over the project manager's head. Eureka! Suddenly, the project manager experienced agile self-organization! The team would figure out what to do on its own. The manager's traditional role—defining all the work and ensuring its completion—shifted to facilitating, coaching and mentoring, guiding the team to do its best. In this agile task transition, the team takes on a great deal of managerial responsibility—to the project's benefit.
This Is Not a Test
Even if you've read about agile processes, heard about agile processes, and can talk about agile processes, you won't truly understand them until you've experienced agility in progress, close-up and personal; otherwise, it's all academic. When introducing agility into new projects, I try to expedite firsthand experience to engender the agile epiphany: that moment when it all comes together and the process seems self-evident.






Injection Attacks
















 
Rounded Rectangle: Investigation Document: Injection Attacks








Table of Contents




















1          Introduction

1.1  What is Injection Attack

Injection Attack is a type of security exploit in which the attacker adds a code to a Web form input box to gain access to resources or make changes to data. It is a request for some action to be performed on a database or in code. Typically, on a Web form for user authentication, when a user enters their name and password into the text boxes provided for them, those values are inserted into a query. If the values entered are found as expected, the user is allowed access; if they aren't found, access is denied.

1.2 Types of Injection Attacks

Weak input validation is a common vulnerability that could allow your application to be exploited by a number of injection attacks. The following are common types of attacks that exploit weak or missing input validation:
·         SQL Injection Attacks
·         Cross Site Scripting (XSS)
·         URL Rewriting/Tempering


2          SQL Injection Attacks

2.1  Introduction

“This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server”.
SQL injection attacks are very critical as attacker can get vital information from server database. To check SQL injection entry points into your web application, find out code from your code base where direct SQL queries are executed on database by accepting some user inputs.
If user input data is crafted in SQL queries to query the database, attacker can inject SQL statements or part of SQL statements as user inputs to extract vital information from database. Even if attacker is successful to crash the application, from the SQL query error shown on browser, attacker can get the information they are looking for. Special characters from user inputs should be handled/escaped properly in such cases.    

2.2  Examples of SQL Injection Attacks

Followings are the some examples of SQL Injection Attacks:

Attack String
1 OR 1=1
1' OR '1'='1
1'1
1 EXEC XP_
1 AND 1=1
1' AND 1=(SELECT COUNT(*) FROM tablenames); --
1 AND USER_NAME() = 'dbo'
'; DESC users; --
1'1
1' AND non_existant_table = '1
' OR username IS NOT NULL OR username = '
1 AND ASCII(LOWER(SUBSTRING((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) > 116
1 UNION ALL SELECT 1,2,3,4,5,6,name FROM sysObjects WHERE xtype = 'U' --
1 UNI/**/ON SELECT ALL FROM WHERE
%31%27%20%4F%52%20%27%31%27%3D%27%31
1' OR '1'='1
&#49&#39&#32&#79&#82&#32&#39&#49&#39&#61&#39&#49

3          Cross Site Scripting (XSS) Attacks

3.1 Introduction

When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called XSS.
The tester should additionally check the web application for XSS (Cross site scripting). Any HTML e.g. <HTML> or any script e.g. <SCRIPT> should not be accepted by the application. If it is, the application can be prone to an attack by Cross Site Scripting.
Attacker can use this method to execute malicious script or URL on victim’s browser. Using cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies.
Many web applications get some user information and pass this information in some variables from different pages.
E.g.: http://www.examplesite.com/index.php?userid=123&query=xyz
Attacker can easily pass some malicious input or <script> as a ‘&query’ parameter which can explore important user/server data on browser.

3.2 Examples of XSS Attacks

Followings are the some examples of XSS Attacks:

Attack String
 <meta http-equiv="refresh" content="0;url=javascript:document.vulnerable=true;">
 <META HTTP-EQUIV="Set-Cookie" Content="USERID=<SCRIPT>document.vulnerable=true</SCRIPT>">
 <SCRIPT>document.vulnerable=true;</SCRIPT>
 <IMG SRC="jav ascript:document.vulnerable=true;">
 <BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=document.vulnerable=true;>
 <<SCRIPT>document.vulnerable=true;//<</SCRIPT>
 <iframe src="javascript:document.vulnerable=true; <
 </TITLE><SCRIPT>document.vulnerable=true;</SCRIPT>
 <BODY BACKGROUND="javascript:document.vulnerable=true;">
 <BGSOUND SRC="javascript:document.vulnerable=true;">
 ¼script¾document.vulnerable=true;¼/script¾
 <FRAMESET><FRAME SRC="javascript:document.vulnerable=true;"></FRAMESET>
 <style><!--</style><script>document.vulnerable=true;//--></script>
 <![CDATA[<!--]]<script>document.vulnerable=true;//--></script>
 <xml src="javascript:document.vulnerable=true;">
 [\xC0][\xBC]script>document.vulnerable=true;[\xC0][\xBC]/script>
 <!-- -- --><script>document.vulnerable=true;</script><!-- -- -->

4          URL Manipulation/Tempering Attacks

4.1 Introduction

URL manipulation, also called URL rewriting, is the process of altering the parameters in a URL (Uniform Resource Locator). Changing some information in the URL may sometimes lead to unintended behavior by the server.
The tester should check if the application passes important information in the query string. This happens when the application uses the HTTP GET method to pass information between the client and the server. The information is passed in parameters in the query string. The tester can modify a parameter value in the query string to check if the server accepts it.
Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can manipulate every input variable passed from this GET request to server in order to get the required information or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for the attacker to get into the application.

4.2 URL Manipulation

By manipulating certain parts of a URL, a hacker can get a web server to deliver web pages he is not supposed to have access to.
On dynamic websites, parameters are mostly passed via the URL as follows:
http://target/forum/?cat=2
The data present in the URL are automatically created by the site and when navigating normally, a user simply clicks on the links proposed by the website. If a user manually modifies the parameter, he can try different values, for example:
http://target/forum/?cat=6
The hacker may potentially obtain access to an area that is usually protected.
In addition, the hacker can get the site to process an unexpected case, for example:
http://target/forum/?cat=***********
In the above example, if the site's designer has not anticipated the case where the data is not a number, the site may enter an unexpected state and reveal information in an error message.

4.3 SQL Injection Attacks in URL

An attacker may abuse the fact that the UserID parameter is passed to the database without sufficient validation. The attacker can manipulate the parameter's value to build malicious SQL statements. For example, setting the value "123 OR 1=1" to the ProductID variable results in the following URL:
In this example the semicolon is used to pass the database server multiple statements in a single execution. The second statement is "DROP TABLE ECF.PERMISSION " which may causes SQL Server to delete the entire table.





4.4 XSS Attacks in URL

By adding some text in <HTML> tag in URL application crashes. Below is the example:

5          Tools

5.1 Introduction

Exploit-Me is a suite (add-ons) of Firefox web application security testing tools designed to be lightweight and easy to use. It includes:
·         SQL Inject-Me
·         XSS-Me
Exploit-Me can be downloaded from following URL: http://labs.securitycompass.com/index.php/exploit-me/
§  SQL Inject-Me: SQL Injection vulnerabilities can cause a lot of damage to a web application. A malicious user can possibly view records, delete records, drop tables or gain access to your server. SQL Inject-Me is the Exploit-Me tool used to test for SQL Injection vulnerabilities. SQL Inject-Me can easily be download as Add-ons in Mozilla Firefox. After installation it can be viewed in Tools tab as shown below:
When we click upon Open SQL Inject Me sidebar, it will open the SQL Injection tool list in left side bar. As shown below:
§  XSS-Me: Cross-Site Scripting (XSS) is a common flaw found web applications. XSS flaws can cause serious damage to a web application. Detecting XSS vulnerabilities early in the development process will help protect a web application from unnecessary flaws. XSS-Me is the Exploit-Me tool used to test for reflected XSS vulnerabilities.
XSS-Me can easily be download as Add-ons in Mozilla Firefox. After installation it can be viewed in Tools tab as shown below:


When we click upon Open XSS Me sidebar, it will open the XSS tool list in left side bar. As shown below:


5.2 Functioning of tool

Step 1: Open the application in Mozilla Firefox. Now from Tools open the SQL Injection-Me tool. As shown below:


On Sidebar, each tab represents a form on the page and lists all the fields. For example it is displaying, Username, Password and Login button:
 



Step 2: If we want to insert any SQL Query Injection in any text box fields (Username or Password) we can select the option from left navigation.
1.       For example if we want to insert SQL Query Injection for Username text field. Select the checkbox and click SQL query from ‘txtLogin’ drop down. It will display selected SQL Query in “Username” textbox of the application as shown below here we are selecting query “1' OR '1'='1”
Now click upon Login button on the application and check the result. Same we can select different SQL Quires from drop down and check the results.
2.       For example if we select query “&#49&#39&#32&#79&#82&#32&#39&#49&#39&#61&#39&#49” from dropdown and click on Login.
Result: Following error will come:

Step3: If you want to execute different quires simultaneously and want to check the results by tool, you need to select the checkboxes from left navigation and click on “Execute” button. It will display results. User can also select “Test all form with all attacks” option, it will execute all selected quires on all forms of application.

It will display results as follows. Error will display in “Red” color and Queries which will execute successfully will display in “Green” color.

5.3 How to customized Quires in Tool library


Step1: Go to “Tool” menu, select SQL Inject me, and then go to options.

Step2:  It will open a pop up window from where user can “Add”, “Remove” SQL quires.