1.

Software Engineering
1.1 The Evolving role of software:
Nowadays, software plays a major role with dual activity. It is a product like a vehicle. As
a product, it delivers the computing potential embodied by computer hardware or a network of
computers that are accessible by local hardware. Whether the product or software resides within a
mobile phone or operates inside a mainframe computer, software is an information transformer
likely to produce, manage, acquire, modify, display or transmit the information.
The software

Provides good product with useful information

Transforms the data so that it can be more useful in a local context
Manages business information to enhance competitiveness
Provides a gateway to worldwide networks like internet

The role of computer software has undergone significant change over a time span
of little more than 50 years.
Software Characteristics:
To make the difference from other things or product, it is important to examine the
characteristics of software. When hardware is built, the human creative process may be
analysis, design, construction, testing is ultimately translated into a physical form where
as build a new computer, the initial sketches, formal design drawings, and bread boarded
prototype evolve into a physical product such as chips, circuit boards, power supplies, etc.
Software is a logical related rather than a physical system. So that the software
have distinct characteristics but the hardware is not so, it is only the peripherals or devices
or components.
Character 1: Software is developed or engineered; it is not manufactured in the
Classical Sense.
Although some similarities exist between software development and hardware
manufacture, the two activities are fundamentally different. In both the activities, high
quality is achieved through good design, but the manufacturing phase for hardware can
introduce quality problems that are nonexistent or easily corrected for software. Both the
activities are dependent on people, but the relationship between people is totally varying.
These two activities require the construction of a "product" but the approaches are
different. Software costs are concentrated in engineering which means that software
projects cannot be managed as if they were manufacturing.

Character 2: Software does not wear out

The figure 1.1 shows the relationship between failure rate and time. Consider the
failure rate as a function of time for hardware. The relationship is called the bathtub
curve, indicates that hardware exhibits relatively high failure rates early in its life, defects
are corrected and the failure rate drops to a steady-state level for some period of time. As
time passes, however, the failure rate rises again as hardware components suffer from the
cumulative effects of dust, vibration, abuse, temperature extremes, and many other
environmental maladies. So, stated simply, the hardware begins to wear out.

Figure 1.1 Relationship between failure rate and time Software is not susceptible
to the environmental maladies that cause hardware to wear out. In theory, therefore, the
failure rate curve for software should take the form of the idealized curve like a zig-zag
form. Undiscovered defects will cause high failure rates early in the life of a program.
However, the implication is clear software doesn't wear out. But it does deteriorate.
Before the curve can return to the original steady-state failure rate, another change is
requested, causing the curve to spike again. Slowly, the minimum failure rate level begins
to risethe software is deteriorating due to change.

Figure 1.2 Idealized and actual failure curves for software when a hardware
component wears out, it are replaced by a spare part unlike the software spare parts. The
software failure indicates an error in design or in the process through which design as
translated into machine executable code. Therefore, software maintenance involves more
complexity than hardware maintenance.
Character 3: Although the industry is moving toward component-based assembly,
most software continues to be custom built
Consider the manner in which the control hardware for a computer-based product
is designed and built. The design engineer draws a simple schematic of the digital
circuitry, does some fundamental analysis to assure that proper function will be achieved,
and then goes to the shelf where catalogs of digital components exist.
Each integrated circuit (called an IC or a chip) has a part number, a defined and
validated function, a well-defined interface, and a standard set of integration guidelines.
After each component is selected, it can be ordered off the shelf. As an engineering
discipline evolves, a collection of standard design components is created. Standard screws
and off-the-shelf integrated circuits are standard components that are used by mechanical
and electrical engineers to design new systems.
The reusable components have been created so that the engineer can concentrate
on the truly innovative elements of a design, that is, the parts of the design that represent
something new. In the hardware world, component reuse is a natural part of the
engineering process.
A software component should be designed and implemented so that it can be
reused in many different programs. In the 1960s, we built scientific subroutine libraries
that were reusable in a broad array of engineering and scientific applications. These
subroutine libraries reused well-defined algorithms in an effective manner but had a
limited domain of application and not extended algorithm only but included data structure
too. Modern reusable components encapsulate both data and the processing applied to the
data, enabling the software engineer to create new applications from reusable parts.

1.2 Changing nature of Software:

Today, software takes on a dual role. It is a product, and at the same time, the vehicle for
delivering a product. As a product, it delivers the computing potential embodied by computer
hardware or more broadly, by a network of computers that are accessible by local hardware.
Whether it resides within a mobile phone or operates inside a mainframe computer, software is
information transformer producing, managing, acquiring, modifying, displaying, or
transmitting information that can be as simple as a single bit or as complex as a multimedia
presentation derived from data acquired from dozens of independent sources. As the vehicle used
to deliver the product, software acts as the basis for the control of the computer (operating
3

systems), the communication of information (networks), and the creation and control of other
programs (software tools and environments).
Software delivers the most important product of our timeinformation. It transforms
personal data (e.g., an individuals financial transactions) so that the data can be more useful in a
local context; it manages business information to enhance competitiveness; it provides a gateway
to worldwide information networks (e.g., the Internet), and provides the means for acquiring
information in all of its forms.
The role of computer software has undergone significant change over the last halfcentury. Dramatic improvements in hardware performance, profound changes in computing
architectures, vast increases in memory and storage capacity, and a wide variety of exotic input
and output options, have all precipitated more sophisticated and complex computer-based
systems. Sophistication and complexity can produce dazzling results when a system succeeds, but
they can also pose huge problems for those who must build complex systems.
Today, a huge software industry has become a dominant factor in the economies of the
industrialized world. Teams of software specialists, each focusing on one part of the technology
required to deliver a complex application, have replaced the lone programmer of an earlier era.
And yet, the questions that were asked of the lone programmer are the same questions that are
asked when modern computer-based systems are built:

Why does it take so long to get software finished?

Why are development costs so high?
Why cant we find all errors before we give the software to our customers?
Why do we spend so much time and effort maintaining existing programs?
Why do we continue to have difficulty in measuring progress as software is being
developed and maintained?

These, and many other questions, are a manifestation of the concern about software and
the manner in which it is developeda concern that has lead to the adoption of software
engineering practice.

1.3 Legacy Software:

Hundreds of thousands of computer programs fall into one of the seven broad application
domains discussed in the preceding subsection. Some of these are state of- the-art softwarejust
released to individuals, industry, and government. But other programs are older, in some cases
much older.
These older programsoften referred to as legacy softwarehave been the focus of
continuous attention and concern since the 1960s. Dayani-Fard and his colleagues [Day99]
describe legacy software in the following way:
4

Legacy software systems . . . were developed decades ago and have been continually
modified to meet changes in business requirements and computing platforms. The proliferation of
such systems is causing headaches for large organizations who find them costly to maintain and
risky to evolve.
Liu and his colleagues [Liu98] extend this description by noting that many legacy
systems remain supportive to core business functions and are indispensable to the business.
Hence, legacy software is characterized by longevity and business criticality.
Unfortunately, there is sometimes one additional characteristic that is present in legacy
softwarepoor quality. Legacy systems sometimes have inextensible designs, convoluted code,
poor or nonexistent documentation, test cases and results that were never archived, a poorly
managed change historythe list can be quite long. And yet, these systems support core
business functions and are indispensable to the business. What to do?
The only reasonable answer may be: Do nothing; at least until the legacy system must
undergo some significant change. If the legacy software meets the needs of its users and runs
reliably, it isnt broken and does not need to be fixed. However, as time passes, legacy systems
often evolve for one or more of the following reasons:
The software must be adapted to meet the needs of new computing environments
or technology.
The software must be enhanced to implement new business requirements.
The software must be extended to make it interoperable with other more modern
systems or databases.
The software must be re-architected to make it viable within a network
environment.
Then these modes of evolution occur, a legacy system must be reengineered so that it
remains viable into the future. The goal of modern software engineering is to devise
methodologies that are founded on the notion of evolution; that is, the notion that software
systems continually change, new software systems are built from the old ones, and . . . all must
interoperate and cooperate with each other.

1.4 Software Myths:

Software mythserroneous beliefs about software and the process that is used to build it
can be traced to the earliest days of computing. Myths have a number of attributes that make
them insidious. For instance, they appear to be reasonable statements of fact (sometimes
containing elements of truth), they have an intuitive feel, and they are often promulgated by
experienced practitioners who know the score.
5

Today, most knowledgeable software engineering professionals recognize myths for what
they aremisleading attitudes that have caused serious problems for managers and practitioners
alike. However, old attitudes and habits are difficult to modify, and remnants of software myths
remain.

Management Myths:
Managers with software responsibility, like managers in most disciplines, are often under
pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a
drowning person who grasps at a straw, a software manager often grasps at belief in a software
myth, if that belief will lessen the pressure (even temporarily).
Myth: We already have a book thats full of standards and procedures for building software.
Wont that provide my people with everything they need to know?
Reality: The book of standards may very well exist, but is it used? Are software practitioners
aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it
adaptable? Is it streamlined to improve time-to-delivery while still maintaining a focus on
quality? In many cases, the answer to all of these questions is no.
Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called
the Mongolian horde concept).
Reality: Software development is not a mechanistic process like manufacturing. In the words of
Brooks [Bro95]: adding people to a late software project makes it later. At first, this statement
may seem counterintuitive. However, as new people are added, people who were working must
spend time educating the newcomers, thereby reducing the amount of time spent on productive
development effort. People can be added but only in a planned and well coordinated manner.
Myth: If I decide to outsource the software project to a third party, I can just relax and let that
firm build it.
Reality: If an organization does not understand how to manage and control software projects
internally, it will invariably struggle when it outsources software projects.

Customer Myths:
A customer who requests computer software may be a person at the next desk, a technical
group down the hall, the marketing/sales department, or an outside company that has requested
software under contract. In many cases, the customer believes myths about software because
software managers and practitioners do little to correct misinformation. Myths lead to false
expectations (by the customer) and, ultimately, dissatisfaction with the developer.
6

Myth: A general statement of objectives is sufficient to begin writing programswe can fill in
the details later.
Reality: Although a comprehensive and stable statement of requirements is not always possible,
an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements
(usually derived iteratively) are developed only through effective and continuous communication
between customer and developer.
Myth: Software requirements continually change, but change can be easily accommodated
because software is flexible.
Reality: It is true that software requirements change, but the impact of change varies with the
time at which it is introduced. When requirements changes are requested early (before design or
code has been started), the cost impact is relatively small. However, as time passes, the cost
impact grows rapidlyresources have been committed, a design framework has been established,
and change can cause upheaval that requires additional resources and major design modification.

Practitioners myths:
Myths that are still believed by software practitioners have been fostered by over 50 years
of programming culture. During the early days, programming was viewed as an art form. Old
ways and attitudes die hard.
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that the sooner you begin writing code, the longer itll take you to
get done. Industry data indicate that between 60 and 80 percent of all effort expended on
software will be expended after it is delivered to the customer for the first time.
Myth: Until I get the program running I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be applied from
the inception of a projectthe technical review. Software reviews (described in Chapter 15) are a
quality filter that have been found to be more effective than testing for finding certain classes
of software defects.
Myth: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a software configuration that includes many
elements. A variety of work products (e.g., models, documents, plans) provide a foundation for
successful engineering and, more important, guidance for software support.

Myth: Software engineering will make us creates voluminous and unnecessary documentation
and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating a quality
product. Better quality leads to reduced rework. And reduced rework results in faster delivery
times.
Many software professionals recognize the fallacy of the myths just described.
Regrettably, habitual attitudes and methods foster poor management and technical practices, even
when reality dictates a better approach. Recognition of software realities is the first step toward
formulation of practical solutions for software engineering.

1.5 Software Engineering A Layered Technology

Although hundreds of authors have developed personal definitions of software
engineering, a definition proposed by Fritz Bauer [NAU69] at the seminal conference on the
subject still serves as a basis for discussion:
[Software engineering is] the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real machines.
Almost every reader will be tempted to add to this definition. It says little about the
technical aspects of software quality; it does not directly address the need for customer
satisfaction or timely product delivery; it omits mention of the importance of measurement and
metrics; it does not state the importance of a mature process. And yet, Bauers definition provides
us with a baseline. What sound engineering principles can be applied to computer software
development? How do we economically build software so that it is reliable? What is required
to create computer programs that work efficiently on not one but many different real
machines? These are the questions that continue to challenge software engineers.
The IEEE [IEE93] has developed a more comprehensive definition when it states:
Software Engineering:
The application of a systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of engineering to software.

1.5.1 Process, Methods, Tools

Software engineering is a layered technology. Referring to Figure 1.5.1.1, any engineering
approach (including software engineering) must rest on an organizational commitment to quality.
8

Total quality management and similar philosophies foster a continuous process improvement
culture, and this culture ultimately leads to the development of increasingly more mature
approaches to software engineering. The bedrock that supports software engineering is a quality
focus.

Fig: 1.5.1.1 Process Methods Tools

The foundation for software engineering is the process layer. Software engineering
process is the glue that holds the technology layers together and enables rational and timely
development of computer software. Process defines a framework for a set of key process areas
(KPAs) [PAU93] that must be established for effective delivery of software engineering
technology. The key process areas form the basis for management control of software projects
and establish the context in which technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured,
and change is properly managed.
Software engineering methods provide the technical how-to's for building software.
Methods encompass a broad array of tasks that include requirements analysis, design, program
construction, testing, and support. Software engineering methods rely on a set of basic principles
that govern each area of the technology and include modelling activities and other descriptive
techniques.
Software engineering tools provide automated or semi-automated support for the process
and the methods. When tools are integrated so that information created by one tool can be used
by another, a system for the support of software development, called computer-aided software
engineering, is established. CASE combines software, hardware, and a software engineering
database (a repository containing important information about analysis, design, program
construction, and testing) to create a software engineering environment analogous to CAD/CAE
(computer-aided design/engineering) for hardware.

1.6 A Generic View of Process:

Engineering is the analysis, design, construction, verification, and management of

technical (or social) entities. Regardless of the entity to be engineered, the following questions
must be asked and answered:

What is the problem to be solved?

What characteristics of the entity are used to solve the problem?
How will the entity (and the solution) be realized?
How will the entity be constructed?
What approach will be used to uncover errors that were made in the design and
construction of the entity?
How will the entity be supported over the long term, when corrections, adaptations, and
enhancements are requested by users of the entity?

Throughout this book, we focus on a single entitycomputer software. To

engineer software adequately, a software engineering process must be
defined. In this section, the generic characteristics of the software process
are considered. Later in this chapter, specific process models are addressed.
The work associated with software engineering can be categorized into three generic phases,
regardless of application area, project size, or complexity. Each phase addresses one or more of
the questions noted previously.
The definition phase focuses on what. That is, during definition, the software engineer
attempts to identify what information is to be processed, what function and performance are
desired, what system behaviour can be expected, what interfaces are to be established, what
design constraints exist, and what validation criteria are required to define a successful system.
The key requirements of the system and the software are identified. Although the methods
applied during the definition phase will vary depending on the software engineering paradigm (or
combination of paradigms) that is applied, three major tasks will occur in some form: system or
information engineering, software project planning, and requirements analysis.
The development phase focuses on how. That is, during development a software engineer
attempts to define how data are to be structured, how function is to be implemented within a
software architecture, how procedural details are to be implemented, how interfaces are to be
characterized, how the design will be translated into a programming language (or nonprocedural
language), and how testing will be performed. The methods applied during the development
phase will vary, but three specific technical tasks should always occur: software design, code
generation, and software testing.
The support phase focuses on change associated with error correction, adaptations required as
the software's environment evolves, and changes due to enhancements brought about by changing
customer requirements. The support phase reapplies the steps of the definition and development
phases but does so in the context of existing software. Four types of change are encountered
during the support phase:
10

Correction: Even with the best quality assurance activities, it is likely that the customer will
uncover defects in the software. Corrective maintenance changes the software to correct defects.

Adaptation: Over time, the original environment (e.g., CPU, operating system, business rules,
external product characteristics) for which the software was developed is likely to change.
Adaptive maintenance results in modification to the software to accommodate changes to its
external environment.

Enhancement: As software is used, the customer/user will recognize additional functions that
will provide benefit. Perfective maintenance extends the software beyond its original functional
requirements.

Prevention: Computer software deteriorates due to change, and because of this, preventive
maintenance, often called software reengineering, and must be conducted to enable the software
to serve the needs of its end users. In essence, preventive maintenance makes changes to
computer programs so that they can be more easily corrected, adapted, and enhanced.
In addition to these support activities, the users of software require continuing support.
In-house technical assistants, telephone-help desks, and application-specific web sites are often
implemented as part of the support phase.
Today, a growing population of legacy programs1 is forcing many companies to pursue
software reengineering strategies. In a global sense, software reengineering is often considered as
part of business process reengineering.
The phases and related steps described in our generic view of software engineering are
complemented by a number of umbrella activities. Typical activities in this category include:

Software project tracking and control

Formal technical reviews
Software quality assurance
Software configuration management
Document preparation and production
Reusability management
Measurement
Risk management.

1.7 Capability Maturity Model Integration (CMMI):

11

A software process can be characterized as shown in Figure 1.7.1. A common process

framework is established by defining a small number of framework activities that are applicable
to all software projects, regardless of their size or complexity. A number of task setseach a
collection of software engineering work tasks, project milestones, work products, and quality
assurance pointsenable the framework activities to be adapted to the characteristics of the
software project and the requirements of the project team. Finally, umbrella activitiessuch as
software quality assurance, software configuration management, and measurement2overlay the
process model. Umbrella activities are independent of any one framework activity and occur
throughout the process.

Fig: 1.7.1 the software Process

In recent years, there has been a significant emphasis on process maturity. The Software
Engineering Institute (SEI) has developed a comprehensive model predicated on a set of software
engineering capabilities that should be present as organizations reach different levels of process
maturity. To determine an organizations current state of process maturity, the SEI uses an
assessment that results in a five point grading scheme. The grading scheme determines
compliance with a capability maturity model (CMM) [PAU93] that defines key activities required
at different levels of process maturity. The SEI approach provides a measure of the global
effectiveness of a company's software engineering practices and establishes five process maturity
levels that are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occasionally even chaotic.
Few processes are defined, and success depends on individual effort.
12

Level 2: Repeatable. Basic project management processes are established to track cost, schedule,
and functionality. The necessary process discipline is in place to repeat earlier successes
on projects with similar applications.
Level 3: Defined. The software process for both management and engineering activities is
documented, standardized, and integrated into an organization wide software process. All
projects use a documented and approved version of the organization's process for
developing and supporting software.
This level includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software process and product quality are collected.
Both the software process and products are quantitatively understood and controlled
using detailed measures. This level includes all characteristics defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from
the process and from testing innovative ideas and technologies.
This level includes all characteristics defined for level 4.
The five levels defined by the SEI were derived as a consequence of evaluating responses
to the SEI assessment questionnaire that is based on the CMM. The results of the questionnaire
are distilled to a single numerical grade that provides an indication of an organization's process
maturity.
The SEI has associated key process areas (KPAs) with each of the maturity levels. The
KPAs describe those software engineering functions (e.g., software project planning,
requirements management) that must be present to satisfy good practice at a particular level. Each
KPA is described by identifying the following characteristics:
Goalsthe overall objectives that the KPA must achieve.
Commitmentsrequirements (imposed on the organization) that must be met to achieve the
goals or provide proof of intent to comply with the goals.
Abilitiesthose things that must be in place (organizationally and technically) to enable the
organization to meet the commitments.
Activitiesthe specific tasks required to achieve the KPA function.
Methods for monitoring implementationthe manner in which the activities are monitored as
they are put into place.
Methods for verifying implementationthe manner in which proper practice for the KPA can
be verified.
13

Eighteen KPAs (each described using these characteristics) are defined across the
maturity model and mapped into different levels of process maturity. The following KPAs should
be achieved at each process maturity level: 3.

Process maturity level 2:

Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight
Software project planning
Requirements management

Process maturity level 3:

Peer reviews
Intergroup coordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus

Process maturity level 4:

Software quality management
Quantitative process management

Process maturity level 5:

Process change management
Technology change management
Defect prevention
Each of the KPAs is defined by a set of key practices that contribute to satisfying its goals.
The key practices are policies, procedures, and activities that must occur before a key process
area has been fully instituted. The SEI defines key indicators as "those key practices or
components of key practices that offer the greatest insight into whether the goals of a key process
area have been achieved." Assessment questions are designed to probe for the existence (or lack
thereof) of a key indicator.
14

1.8 A Process Framework

Software process models can be prescriptive or agile, complex or simple, allencompassing or targeted, but in every case, five key activities must occur. The framework
activities are applicable to all projects and all application domains, and they are a template for
every process model.
Software process
Process framework
Umbrella activities
Framework activity #1
Software Engineering action

Fig: 1.8.1 A Process Framework

15

Each framework activity is populated by a set of S/W eng actions a collection of related
tasks that produces a major S/W eng work product (design is a S/W eng action). Each action is
populated with individual work tasks that accomplish some part of the work implied by the
action.
The following generic process framework is applicable to the vast majority of S/W
projects.
Communication: involves heavy communication with the customer (and other
and encompasses requirements gathering.

stakeholders)

Planning: Describes the technical tasks to be conducted, the risks that are likely, resources that
will be required, the work products to be produced and a work schedule.
Modeling: encompasses the creation of models that allow the developer and customer to better
understand S/W req. and the design that will achieve that req.
Construction: combines code generation and the testing required uncovering errors in the code.
Deployment: deliver the product to the customer who evaluates the delivered product and
provides feedback.
Each S/W eng action is represented by a number of different task sets each a collection
of S/W eng work tasks, related work products, quality assurance points, and project milestones.
The task set that best accommodates the needs of the project and the characteristics of the
team is chosen.
The framework described in the generic view of S/W eng is complemented by a number
of umbrella activities. Typical activities include:
S/W project tracking and control: allows the team to assess progress against the project
plan and take necessary action to maintain schedule.
Risk Management: Assesses the risks that may affect the outcome of the project or the
quality.
Software quality assurance: defines and conducts the activities required to ensure
software quality.
Formal Technical Review: uncover and remove errors before they propagate to the next
action.
Measurement: defines and collects process, project, and product measures that assist the
team in delivering S/W that meets customers needs.
Software configuration management: Manages the effect of change throughout the S/W
process
16

Reusability management: defines criteria for work product reuse.

Work product preparation and production: encompasses the activities required to
create work products such as models, documents, etc.

1.9 Process Patterns:

To define what a process pattern is, I would first like to explore its two root words:
process and pattern. A process is defined as a series of actions in which one or more inputs are
used to produce one or more outputs. Defining a pattern is a little more difficult. Alexander
(1979) hints at the definition of a pattern by pointing out that the same broad features keep
recurring over and over again, although in their detailed appearance these broad features are
never the same. Alexander shows that although every building is unique, each may be created by
following a collection of general patterns. In other words, a pattern is a general solution to a
common problem or issue, one from which a specific solution may be derived.

1.9.1 Types of Process Patterns:

One feature which I believe is important for process patterns is that it be possible to
develop them for all aspects of development. The point to be made is that the scope of a single
process pattern may range from a high-level view of how applications are developed to a moredetailed view of a specific portion of the software process.
I believe that there are three types of process patterns. In order of increasing scale they
are:

1. Task process patterns:

This type of process pattern depicts the detailed steps to perform a specific task,
such as the Technical Review and Reuse First process patterns.
2. Stage process patterns:
This type of process pattern depicts the steps, which are often performed
iteratively, of a single project stage. A project stage is a higher-level form of process
pattern, one that is often composed of several task process patterns. A stage process
pattern is presented for each project stage of a software process.
3. Phase process patterns:
This type of process pattern depicts the interactions between the stage process
patterns for a single project phase, such as the Initiate and Delivery phases. A phase
process pattern is a collection of two or more stage process patterns. Project phases are
performed in a serial manner; this is true of both structured development and of object
development. A common myth within the object industry is that object-oriented (OO)
17

development is iterative in nature. Although this may be true of the small, pilot projects
prevalent in the early 1990s, it is not true of todays large-scale, mission-critical
applications. The reality is that OO development is serial in the large, iterative in the
small, delivering incremental releases over time (Ambler, 1998b). Phase process patterns
are performed in serial order, made up of stage process patterns which are performed
iteratively.

1.10 Process Assessment:

SEI SW-CMM Improvement Approach: IDEAL
-

Initiating

Diagnosing

Establishing

Acting

Leveraging

Diagnose process, establish priorities, & act on them

Initiating:

Stimulus for improvement

Set context & sponsorship

Establish improvement infrastructure

Diagnosing:
-

Appraise & characterize current practice

Develop recommendations

Document phase results

Establishing:
-

Set strategy & priorities

Establish process action items

Plan actions

18

Acting:
-

Define processes and measures

Plan & execute pilots

Plan, execute, & track installation

Leveraging:
-

Document & analyze lessons

Revise organizational approach

General Classes of SW-CMM Appraisal

-

Software Process Assessment

Software Capability Evaluations

Determine state of organizations software process

Identify contractors qualified to perform software work

Software Process Assessment:

-

Identify improvement priorities within organization

Assessment team uses CMM to guide identifying & prioritizing findings

Findings & KPA guidance used to plan improvement strategy for organization

Software Capability Evaluations:

-

Identify risks associated with a project or contract to build high quality on

schedule & budget

During acquisition process, capability evaluation may be performed on bidders

Findings of an evaluation may be used to identify risk with using a contractor

Performed on existing contracts to monitor process performance

Software Process Assessment & Capability Evaluation Steps:

19

Fig: 1.10.1 Steps of Process Assessment

Common Steps
-

On-site Visit
Using results analysis, conduct on-site visit to view process areas
Using KPAs as guide, question, listen, review & synthesize info
Apply professional judgment
Document rationale for situations where KPAs not met

Findings
At end of on-site period, team produces list of findings
Identifies strengths & weaknesses of orgs software processes
Software Process Assessment -> Basis for PI recommendations
Software Capability Evaluation -> Findings part of risk analysis

20

KPA Profile
Team prepares KPA profile, showing where KPAs satisfied / not satisfied
by organization

KPA can be satisfied and still have associated findings, as long as findings
dont identify major problems achieving goals of KPA

Differences: Process Assessments & Capability Evaluation

-

Results of process assessment or capability evaluation may differ

Assessment / evaluation scope may vary:

Different definitions of Organization
Org may be based on senior management, geo location, common app,
profit/loss center, etc.
Sample of selected projects

Motivation, objective, outcome & results ownership differ

These factors lead to differences in dynamics of interviews, scope of
inquiry, info collected, & results
Assessment & evaluation methods are different
Assessment training doesnt prepare team to do evaluation, vice versa

Process Assessment performed in open, collaborative environment

Commitment from mgmt & staff to do process improvement
Objective: surface problems & help improve organization
Emphasis on interviews as tool for understanding organizations software
process

Capability Evaluation performed in audit-oriented environment

Objective tied to monetary considerations
Emphasis on documented audit trail that reveals software process actually
implemented by organization
21

1.11 Personal and Team Process Models:

Personal Process Models:
The Personal Software Process (PSP) shows engineers how to
-

manage the quality of their projects

make commitments they can meet

improve estimating and planning

reduce defects in their products

PSP emphasizes the need to record and analyze the types of errors you make, so you can
develop strategies eliminate them.

PSP Model Framework Activities:

Planning isolates requirements and based on these develops both size & resource
estimates. A defect estimate is made.
High level Design external specification of all components. All issues are recorded and
tracked.
High level Design Review- formal verification to uncover errors.
Development- metrics are maintained for all important tasks & work results.
Postmortem- using measures & metrics collected effectiveness of process is determined
an improved.

Because personnel costs constitute 70 percent of the cost of software development, the
skills and work habits of engineers largely determine the results of the software development
process.
Based on practices found in the CMMI, the PSP can be used by engineers as a guide to a
disciplined and structured approach to developing software. The PSP is a prerequisite for an
organization planning to introduce the TSP.
The PSP can be applied to many parts of the software development process, including
- Small-program development
- Requirement definition
- Document writing
22

- Systems tests
- Systems maintenance
- Enhancement of large software systems

Team Process Models:

The Team Software Process (TSP), along with the Personal Software Process, helps the
high-performance engineer to
- ensure quality software products
- create secure software products
- improve process management in an organization

Team Process Models:

Launch high level design

Implementation
Integration
Test
postmortem

TSP:
Engineering groups use the TSP to apply integrated team concepts to the development of
software-intensive systems. A launch process walks teams and their managers through
- establishing goals
- defining team roles
- assessing risks
- producing a team plan

Benefits:
The TSP provides a defined process framework for managing, tracking and reporting the
team's progress.
Using TSP, an organization can build self-directed teams that plan and track their work,
establish goals, and own their processes and plans. These can be pure software teams or
integrated product teams of 3 to 20 engineers.
23

 TSP will help your organization establish a mature and disciplined engineering practice
that produces secure, reliable software.

2. Network Security
2.1 Security Attacks
Introduction:
We start our description of security in distributed systems by taking a look at some
general security issues. First, it is necessary to define what a secure system is. We distinguish
security policies from security mechanisms, and take a look at the Globus wide-area system for
which a security policy has been explicitly formulated. Our second concern is to consider some
general design issues for secure systems. Finally, we briefly discuss some cryptographic
algorithms, which play a key role in the design of security protocols.
Security in computer systems is strongly related to the notion of dependability.
Informally, a dependable computer system is one that we justifiably trust to deliver its services
(Laprie, 1995). Dependability includes availability, reliability, safety, and maintainability.
However, if we are to put our trust in a computer system, then confidentiality and integrity should
also be taken into account. Confidentiality refers to the property of a computer system whereby
its information is disclosed only to authorize parties. Integrity is the characteristic that alterations
to a systems assets can be made only in an authorized way. In other words, improper alterations
in a secure computer system should be detectable and recoverable. Major assets of any computer
system are its hardware, software, and data. Another way of looking at security in computer
systems is that we attempt to protect the services and data it offers against security threats.
There are mainly two types of attacks:

1) Passive attacks:
Attempts to learn or make use of information from the system but does not affect
system resources
a) Traffic Analysis
b) Release of message contents
a) Traffic Analysis:
In this attack the eavesdropper analyzes the traffic, determines the location,
identifies communicating hosts, observes the frequency and length of message being
exchanged. Using all these information they predict the nature of communication. All
incoming and outgoing traffic of network is analysed but not altered.
24

b) Release of message contents:

Release of message content: A telephonic conversation, an E-mail message or a
transferred file may contain confidential data. A passive attack may monitor the contents
of this transmission.
gaining knowledge of data by observing the characteristics of communications that
carry the data
Even if message contents is encrypted, an attacker can still
determine the identity and the location of the communicating parties
observe the frequency and length of the messages being exchanged
guess the nature of the communication
Difficult to detect, should be prevented

2) Active attacks:
Attempts to alter system resources or affect their operation
Examples:
Masquerade (spoofing)
An entity pretends to be a different entity
Replay
Capture and subsequent retransmission of data
Modification (substitution, insertion, destruction)
(some parts of the) legitimate messages are altered or deleted, or fake messages are
generated
If done in real time, then it needs a man in the middle
Denial of service
Normal use or management of the system is prevented or inhibited
e.g., a server is flooded by fake requests so that it cannot reply normal requests
Difficult to prevent, should be detected
There are four types of security threats to consider:

25

Fig: 2.1.1 Types of Security Attacks

1. Interception
2. Interruption
3. Modification
4. Fabrication
1. Interception:
Interception refers to the situation that an unauthorized party has gained access to
a service or data.
A typical example of interception is where communication between two
has been overheard by someone else.

parties

2. Interruption:
Interception also happens when data are illegally copied, for example, after
breaking into a persons private directory in a file system.
An example of interruption is when a file is corrupted or lost. In general,
interruption refers to the situation in which services or data become unavailable, unusable,
destroyed, and so on. In this sense, denial of service attacks by which someone
maliciously attempts to make a service inaccessible to other parties is a security threat
that classifies as interruption.
3. Modification:
26

Modifications involve unauthorized changing of data or tampering with a service

so that it no longer adheres to its original specifications.
Examples of modifications include intercepting and subsequently changing
transmitted data, tampering with database entries, and changing a program so that it
secretly logs the activities of its user.
4. Fabrication:
Fabrication refers to the situation in which additional data or activity are generated
that would normally not exist.
For example, an intruder may attempt to add an entry into a password file or database.
Likewise, it is sometimes possible to break into a system by replaying previously sent
messages.

2.2 Security Services:

In computing, Network Security Services (NSS) comprises a set of libraries designed to
support cross-platform development of security-enabled client and server applications with
optional support for hardware SSL acceleration on the server side and hardware smart cards on
the client side.
There are types of security services:
1)
2)
3)
4)
5)
6)

Confidentiality
Authentication
Integrity
Non-repudiation
Access Control
Availability

1) Confidentiality:
The concept of Confidentiality in information security pertains to the protection of
information and prevention of unauthorized access or disclosure. The ability to keep data
confidential, or secret, is critical to staying competitive in todays business environments.
Loss of confidentiality jeopardizes system and corporate integrity.
Threats to confidentiality:
Hackers
27

A hacker is an individual who is skilled at bypassing controls and

accessing data or information that he or she has not been given
authorization to do so.

Masqueraders
Authorized users on the system that have obtained another person
credentials.
Unauthorized Users
Users that gain access to the system even if company rules forbid it.
Unprotected Downloads
Downloads of files from secure environments to non-secure environments
or media.
Malware
Virus and worms and other malicious software
Software hooks (Trapdoors)
During the development phase software developers create hooks that
allow them to bypass authentication processes and access the internal
workings of the program. When the product development phase is over
developers do not always remember the hooks and may leave them in
place to be exploited by hackers.

2) Authentication:

Authentication is the process by which the information system assures that you are
who you say you are; how you prove your identity is authentic.
Methods of performing authentication are:
User ID and passwords. The system compares the given password with a stored
password. If the two passwords match then the user is authentic.
Swipe card, which has a magnetic strip embedded, which would already contain
your details, so that no physical data entry takes place or just a PIN is entered.
Digital certificate, an encrypted piece of data which contains information about its
owner, creator, generation and expiration dates, and other data to uniquely identify
a user.
key fob, small electronic devices which generate a new random password
synchronized to the main computer
Biometrics - retinal scanners and fingerprint readers. Parts of the body are
considered unique enough to allow authentication to computer systems based one
their properties.
For a very secure environment, it is also possible to combine several of these options,
such as by having fingerprint identification along with user ID and key fob.
28

3) Integrity:

Integrity deals with prevention of unauthorized modification of intentional or accidental

modification.
This concept further breaks down into authenticity, accountability, and non-repudiation.
Authenticity means that the information is from whomever we expect it to be and
whatever we expect it to be.
Accountability means that the information has an owner or custodian who will
stand by its contents.
Non-repudiation is a property achieved through cryptographic methods which
prevents an individual or entity from denying having performed a particular action
related to data

4) Non-repudiation:

Data flows around the internet at the speed of light, or as close to it as the servers allow.
There are hackers, spoofers, sniffers, and worse out there just waiting to steal, alter, and
corrupt your information.
Data consumers need to be able to trust that the data has not been altered, and that its
source is authentic.
Through the use of security related mechanisms, producers and consumers of data can be
assured that the data remains trustworthy across untrusted networks such as the internet,
and even internal intranets.

5) Access Control:
The purpose of access control is to limit the actions or operations that a legitimate user of
a computer system can perform. Access control constrains what a user can do directly, as well as
what programs executing on behalf of the users are allowed to do. In this way access control
seeks to prevent activity that could lead to a breach of security.
Access control relies on and coexists with other security services in a computer system.
Access control is concerned with limiting the activity of legitimate users. It is enforced by a
reference monitor which mediates every attempted access by a user ( or program executing on
behalf of that user) to objects in the system. The reference monitor consults an authorization
database in order to determine if the user attempting to do an operation is actually authorized to
perform that operation. Authorizations in this database are administered and maintained by a
security administrator. The administrator sets these authorizations on the basis of the security
policy of the organisation. Users may also be able to modify some portion of the authorization
database, for instance, to set permissions for their personal files. Auditing monitors and keeps a
record of relevant activity in the system.

29

It is important to make a clear distinction between authentication and access control.

Correctly establishing the identity of the user is the responsibility of the authentication service.
Access control assumes that the authentication of the user has been successfully verified prior to
enforcement of access control via a reference monitor.

6) Availability:
Availability assures that the resources that need to be accessed are accessible to
authorized parties in the ways they are needed. Availability is a natural result of the other
two concepts. If the confidentiality and integrity of the systems are assured their
availability for the purpose they are intended for is a direct consequence.

Threats to Availability :

Availability can be affected by a number of events which break down into human
and non human influenced factors. This further break down to unintentional and
intentional acts.
Examples of unintentional (non-directed) acts can be overwriting, in part or whole,
of data, compromising of systems, or network infrastructure by organizational
staff.
Intentional acts can be conventional warfare (bombs and air-strikes), information
warfare denial of service (DoS) and distributed denial of service (DDoS).
Non-human factors include loss of availability due to fires, floods, earthquakes
and storms.

2.3 Security Mechanisms:

X.800 defines the following mechanisms

2.3.1. Specific security mechanisms:

May be incorporated into the appropriate protocol layer in order to provide some
of OSI security services
1.1.

Encipherment

30

The use of mathematical algorithms to transform data into a form that is

not readily intelligible. The transformation and subsequent recovery of the data
depend on an algorithm and zero or more encryption keys
1.2.

Digital signature
Data appended to, or a cryptographic transformation of, a data unit that
allows a recipient of the data unit to prove the source and integrity of the data
unit and protect against forgery

1.3.

Access control
A variety of mechanisms that enforce access rights to resources

1.4.

Data integrity
A variety of mechanisms used to assure the integrity of a data unit or
stream of data units

1.5.

Authentication exchange
A mechanism intended to ensure the identity of an entity by means of
information exchange

1.6.

Traffic padding
The insertion of bits into gaps in a data stream to frustrate traffic analysis
attempts

1.7.

Routing control
Enables selection of a particular physically secure routes for certain data
and allows routing changes, especially when a breach of security is suspected

1.8.

Notarization
The use of the third trusted party to assure certain properties of a data
exchange

2.3.2 Pervasive security mechanisms:

Mechanisms, not specific to any particular OSI security service or protocol layer
1. Trusted Functionality:
That which is perceived to be correct with respect to some other criteria (e.g.
as established by security policy)
2. Security label:
31

The marking bound to a resource (which may be a data unit) that names or
designates the security attributes of that resources.
3. Event detection:
Detection of security relevant events.
4. Security audit trail:
Data collected and potentially used to facilitate a security audit, which is
independent review and examination of system records and activities

5. Security recovery:
Deals with requests from mechanisms, such as event handling and
management functions, and takes recovery actions.

2.4 A Model for Internet Security:

A model for much of what we will be discussing is captured, in very general terms, in
Figure 2.4.1. A message is to be transferred from one party to another across some sort of
Internet service. The two parties, who are the principals in this transaction, must cooperate for the
exchange to take place. A logical information channel is established by defining a route through
the Internet from source to destination and by the cooperative use of communication protocols
(e.g., TCP/IP) by the two principals. Security aspects come into play when it is necessary or
desirable to protect the information transmission from an opponent who may present a threat to
confidentiality, authenticity, and so on.
All of the techniques for providing security have two components:
1. A security-related transformation on the information to be sent. Examples include the
encryption of the message, which scrambles the message so that it is unreadable by
the opponent, and the addition of a code based on the contents of the message, which
can be used to verify the identity of the sender.
2. Some secret information shared by the two principals and, it is hoped, unknown to the
opponent. An example is an encryption key used in conjunction with the
transformation to scramble the message before transmission and unscramble it on
reception.

32

Fig: 2.4.1 Model for Internet Security

A trusted third party may be needed to achieve secure transmission. For example, a third
party may be responsible for distributing the secret information to the two principals while
keeping it from any opponent. Or a third party may be needed to arbitrate disputes between the
two principals concerning the authenticity of a message transmission.
This general model shows that there are four basic tasks in designing a particular security
service:
1. Design an algorithm for performing the security-related transformation. The algorithm should
be such that an opponent cannot defeat its purpose.
2. Generate the secret information to be used with the algorithm.
3. Develop methods for the distribution and sharing of the secret information.
4. Specify a protocol to be used by the two principals that makes use of the security and the secret
information to achieve a particular security service.
Parts One and Two of this book concentrate on the types of security mechanisms and
services that fit into the model shown in Figure 2.4.2. However, there are other security-related
situations of interest that do not neatly fit this model but are considered in this book. A general
model of these other situations is illustrated by Figure 2.4.2, which reflects a concern for
protecting an information system from unwanted access. Most readers are familiar with the
concerns caused by the existence of hackers who attempt to penetrate systems that can be
accessed over a network. The hacker can be someone who, with no malign intent, simply gets
satisfaction from breaking and entering a computer system. The intruder can be a disgruntled
33

employee who wishes to do damage or a criminal who seeks to exploit computer assets for
financial gain (e.g., obtaining credit card numbers or performing illegal money transfers).
Another type of unwanted access is the placement in a computer system of logic that exploits
vulnerabilities in the system and that can affect application programs as well as utility programs,
such as editors and compilers. Programs can present two kinds of threats:
1. Information access threats: Intercept or modify data on behalf of users who should not
have access to that data.
2. Service threats: Exploit service flaws in computers to inhibit use by legitimate users.

Fig: 2.4.2 Network Access Security Model

Viruses and worms are two examples of software attacks. Such attacks can be introduced
into a system by means of a disk that contains the unwanted logic concealed in otherwise useful
software. They also can be inserted into a system across a network; this latter mechanism is of
more concern in network security. The security mechanisms needed to cope with unwanted
access fall into two broad categories (see Figure 2.4.2). The first category might be termed a
gatekeeper function. It includes password-based login procedures that are designed to deny
access to all but authorized users and screening logic that is designed to detect and reject worms,
viruses, and other similar attacks. Once either an unwanted user or unwanted software gains
access, the second line of defence consists of a variety of internal controls that monitor activity
and analyze stored information in an attempt to detect the presence of unwanted intruders.

2.5 Internet Standards and RFCs:

The Internet Society is the coordinating committee for Internet design, engineering, and
management. Areas covered include the operation of the Internet itself and the standardization of
protocols used by end systems on the Internet for interoperability. Three organizations under the
Internet Society are responsible for the actual work of standards development and publication:
Internet Architecture Board (IAB): Responsible for defining the overall architecture of the
Internet, providing guidance and broad direction to the IETF
Internet Engineering Task Force (IETF): The protocol engineering and development arm of
the Internet

34

 Internet Engineering Steering Group (IESG): Responsible for technical management of

IETF activities and the Internet standards process.
Working groups chartered by the IETF carry out the actual development of new standards
and protocols for the Internet. Membership in a working group is voluntary; any interested party
may participate. During the development of a specification, a working group will make a draft
version of the document available as an Internet Draft, which is placed in the IETF's "Internet
Drafts" online directory. The document may remain as an Internet Draft for up to six months, and
interested parties may review and comment on the draft. During that time, the IESG may approve
publication of the draft as an RFC (Request for Comment). If the draft has not progressed to the
status of an RFC during the six-month period, it is withdrawn from the directory. The working
group may subsequently publish a revised version of the draft.
The IETF is responsible for publishing the RFCs, with approval of the IESG. The RFCs
are the working notes of the Internet research and development community. A document in this
series may be on essentially any topic related to computer communications and may be anything
from a meeting report to the specification of a standard.

Internet Standards Categories:

All Internet standards fall into one of two categories:
Technical specification (TS): A TS defines a protocol, service, procedure, convention, or format.
The bulk of the Internet standards are TSs.
D -7
Applicability statement (AS): An AS specifies how, and under what circumstances, one or more
TSs may be applied to support a particular Internet capability. An AS identifies one or more TSs
that is relevant to the capability, and may specify values or ranges for particular parameters
associated with a TS or functional subsets of TS that are relevant for the capability.

Other RFC Types:

There are numerous RFCs that are not destined to become Internet standards. Some RFCs
standardize the results of community deliberations about statements of principle or conclusions
about what is the best way to perform some operations or IETF process function. Such RFCs are
designated as Best Current Practice (BCP). Approval of BCPs follows essentially the same
process for approval of Proposed Standards. Unlike standards-track documents, there is not a
three-stage process for BCPs; a BCP goes from Internet draft status to approved BCP in one step.
A protocol or other specification that is not considered ready for standardization may be
published as an Experimental RFC. After further work, the specification may be resubmitted. If
the specification is generally stable, has resolved known design choices, is believed to be well
understood, has received significant community review, and appears to enjoy enough community
interest to be considered valuable, then the RFC will be designated a Proposed Standard.
Finally, an Informational Specification is published for the general information of the
Internet community.

35

2.6 Buffer overflow & Format String Vulnerabilities:

Buffer overflow is probably the best known form of software security vulnerability. Most
software developers know what buffer overflow vulnerability is, but buffer overflow attacks
against both legacy and newly-developed applications are still quite common. Part of the
problem is due to the wide variety of ways buffer overflows can occur, and part is due to the
error-prone techniques often used to prevent them.
In a classic buffer overflow exploit, the attacker sends data to a program, which it stores
in an undersized stack buffer. The result is that information on the call stack is overwritten,
including the function's return pointer. The data sets the value of the return pointer so that when
the function returns, it transfers control to malicious code contained in the attacker's data.
Although this type of stack buffer overflow is still common on some platforms and in
some development communities, there are a variety of other types of buffer overflow, including
heap buffer overflows and off-by-one errors among others. There are a number of excellent
books that provide detailed information on how buffer overflow attacks work, including
Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].
At the code level, buffer overflow vulnerabilities usually involve the violation of a
programmer's assumptions. Many memory manipulation functions in C and C++ do not perform
bounds checking and can easily exceed the allocated bounds of the buffers they operate upon.
Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The
combination of memory manipulation and mistaken assumptions about the size or makeup of a
piece of data is the root cause of most buffer overflows.
In this case, an improperly constructed format string causes the program to write beyond
the bounds of allocated memory.
Example: The following code overflows buf because, depending on the size of f, the format
string specifier "%d %.1f ... " can exceed the amount of allocated memory.
void formatString(int x, float f) {
char buf[40];
sprintf(buf, "%d %.1f ... ", x, f);
}

2.7 TCP session hijacking:

2.7.1 Introduction:
TCP an abbreviation for Transmission Control Protocol, one of the main connections
oriented protocol in a TCP/IP network. TCP was formally defined in RFC 793 (while extensions
are given in RFC 1323), as a protocol for providing a reliable end -to-end communication on a
non-reliable network. To establish a session or a connection with a TCP server, a client must have
to follow a structured system for session management; this system is known as Three Way
Handshake. For two machines to communicate via TCP they must have to synchronize their
session through Synchronize and Acknowledgement Packets. Every single packet is given a
36

sequence number which helps the receiving host to synchronize and reassemble the stream of
packets back into their original and intended order.
TCP session establishment is shown in figure:

Fig: 2.7.1 Session Establishment

1. 1. Client sends a SYN request to server with initial sequence number X.

2. 2. Server sends the SYN/ACK packet publishing its own Sequence number SEQ y and
Acknowledgement number ACK for the clients original SYN packet. The ACK indicates the
next SEQ number expected from client by the server.
3. 3. Client acknowledges the receipt of the SYN/ACK packet from the server by sending the
ACK number which will be the next sequence number expected from the server, y+1 in this case.
The following example shows the three-way handshake, using TCP dump to display the
exchange:
tclient.net.39904 > telnet.com.23: S 733381829:733381829(0) win 8760 <mss
1460> (DF)
telnet.com.23 > tclient.net.39904: S 1192930639:1192930639(0) ack 733381830 win 1024 <mss
1460> (DF)
tclient.net.39904 > telnet.com.23: . ack 1 win 8760 (DF)
(Reference from New Riders Intrusion Detection 3rd edition)
tclient at port 39904 attempting to establish session with telnet.com at 23 port with SEQ number
marked by S (start:end(bytes)) flag ; publishing its Window size which is the buffer size i.e. 8760
in this case and also publishing Maximum Segment Size(mss).
Rest all communication follows the standard handshake mechanism After the session
establishment its mere a matter of sending and receiving packets and increasing the sequence and
the acknowledgement numbers accordingly.

2.7.2 Session hijacking:

37

TCP hijacks are meant to intercept the already established TCP sessions between any two
communicating parties and then pretending to be one of them, finally redirecting the TCP traffic
to it by injecting spoofed IP packets so that your commands are processed on behalf of the
authenticated host of the session. It desynchronizes the session between the actual
communicating parties and by intruding itself in between. As authentication is only required at
the time of establishing connection , an already established connection can be easily stolen
without going through any sort of authentication or security measures concerned. TCP session
hijacks can be implemented in two different ways: Middle Man Attack (suggested by Lam,
LeBlanc, and Smith) and the Blind attack.
IP Spoofing: Assuming the identity
Spoofing is pretending to be someone else. This is a technique used to gain unauthorized
access to the computer with an IP address of a trusted host. The trusted host in case of session
hijacking is the client with whose IP address we will spoof our packets so that our packets will
become acceptable to the server maintaining the session with the client. In implementing this
technique session hijacker has to obtain the IP address of the client and inject his own packets
spoofed with the IP address of client into the TCP session, so as to fool the server that it is
communicating with the victim i.e. the original host.
What remains untouched is how to alter the sequence and the acknowledgement numbers
of the spoofed packets which the server is expecting from the client. Once it is altered, hijacker
injects its own forged packet in the established session before the client can respond , ultimately
desynchronizing the original session , because now our server will expect a different sequence
number , so the original packet will be trashed. Based on the anticipation of sequence numbers
there are two types of TCP hijacking: Man in the Middle and Blind hijacking.

2.8 Man in the Middle attacks:

This technique involves using a packet sniffer to intercept the communication between
client and the server. Packet sniffer comes in two categories: Active and Passive sniffers. Passive
sniffers monitors and sniffs packet from a network having same collision domain i.e. network
with a hub, as all packets are broadcasted on each port of hub. Active sniffers works with
Switched LAN network by ARP spoofing (For more information on Active Sniffers refer Ethical
Hacking and Countermeasures EC Council Exam 312 50 (OSB- 2004)).Once the hijacker reads
the TCP header, he can know the sequence number expected by the server, the acknowledgement
number, the ports and the protocol numbers; so that hijacker can forge the packet and send it to
the server before the client does so.
Another way of doing so is to change the default gateway of the clients machine so that it
will route its packets via the hijackers machine. This can be done by ARP spoofing (i.e. by
sending malicious ARP packets mapping its MAC address to the default gateways address so as
to update the ARP cache on the client , to redirect the traffic to hijacker).

2.9 UDP Session Hijacking:

38

Since UDP does not use packet sequencing and synchronizing; it is easier than TCP to
hijack UDP session. The hijacker has simply to forge a server reply to a client UDP request
before the server can respond. If sniffing is used than it will be easier to control the traffic
generating from the side of the server and thus restricting servers reply to the client in the first
place.

2.10 ARP Attacks:

What Is ARP Spoofing?

ARP spoofing is a type of attack in which a malicious actor sends falsified ARP (Address
Resolution Protocol) messages over a local area network. This results in the linking of an
attackers MAC address with the IP address of a legitimate computer or server on the network.
Once the attackers MAC address is connected to an authentic IP address, the attacker will begin
receiving any data that is intended for that IP address. ARP spoofing can enable malicious parties
to intercept, modify or even stop data in-transit. ARP spoofing attacks can only occur on local
area networks that utilize the Address Resolution Protocol.

ARP Spoofing Attacks:

The effects of ARP spoofing attacks can have serious implications for enterprises. In their
most basic application, ARP spoofing attacks are used to steal sensitive information. Beyond this,
ARP spoofing attacks are often used to facilitate other attacks such as:

Denial-of-service attacks: DoS attacks often leverage ARP spoofing to link multiple IP
addresses with a single targets MAC address. As a result, traffic that is intended for many
different IP addresses will be redirected to the targets MAC address, overloading the target
with traffic.
Session hijacking: Session hijacking attacks can use ARP spoofing to steal session IDs,
granting attackers access to private systems and data.
Man-in-the-middle attacks: MITM attacks can rely on ARP spoofing to intercept and
modify traffic between victims.

2.11 Route table Modification:

A routing table is a set of rules, often viewed in table format that is used to determine
where data packets traveling over an Internet Protocol (IP) network will be directed. All IPenabled devices, including routers and switches, use routing tables.
39

A routing table contains the information necessary to forward a packet along the best path
toward its destination. Each packet contains information about its origin and destination. When a
packet is received, a network device examines the packet and matches it to the routing table entry
providing the best match for its destination. The table then provides the device with instructions
for sending the packet to the next hop on its route across the network.
A basic routing table includes the following information:

Destination: The IP address of the packet's final destination

Next hop: The IP address to which the packet is forwarded

Interface: The outgoing network interface the device should use when forwarding the
packet to the next hop or final destination

Metric: Assigns a cost to each available route so that the most cost-effective path can be
chosen

Routes: Includes directly-attached subnets, indirect subnets that are not attached to the
device but can be accessed through one or more hops, and default routes to use for certain
types of traffic or when information is lacking.
Routing tables can be maintained manually or dynamically. Tables for static network

devices do not change unless a network administrator manually changes them. In dynamic
routing, devices build and maintain their routing tables automatically by using routing protocols
to exchange information about the surrounding network topology. Dynamic routing tables allow
devices to "listen" to the network and respond to occurrences like device failures and network
congestion.

2.12 Conventional Encryption Algorithms:

A symmetric encryption scheme has five ingredients (Figure 2.12.1):

40

 Plaintext: This is the original message or data that is fed into the algorithm as input.
Encryption algorithm: The encryption algorithm performs various substitutions and
transformations on the plaintext.
Secret key: The secret key is also input to the algorithm. The exact substitutions and
transformations performed by the algorithm depend on the key.
Cipher text: This is the scrambled message produced as output. It depends on the plaintext and
the secret key. For a given message, two different keys will produce two different cipher texts.
Decryption algorithm: This is essentially the encryption algorithm run in reverse. It takes the
cipher text and the same secret key and produces the original plaintext.
There are two requirements for secure use of symmetric encryption:
1. We need a strong encryption algorithm. At a minimum, we would like the algorithm to be such
that an opponent who knows the algorithm and has access to one or more cipher texts would be
unable to decipher the cipher text or figure out the key. This requirement is usually stated in a
stronger form: The opponent should be unable to decrypt cipher text or discover the key even if
he or she is in possession of a number of cipher texts together with the plaintext that produced
each cipher text.
2. Sender and receiver must have obtained copies of the secret key in a secure fashion and must
keep the key secure. If someone can discover the key and knows the algorithm, all
communication using this key is readable.

2.12.1 Cryptography:
Cryptographic systems are generically classified along three independent dimensions:
1. The type of operations used for transforming plaintext to cipher text. All encryption algorithms
are based on two general principles: substitution, in which each element in the plaintext (bit,
letter, group of bits or letters) is mapped into another element, and transposition, in which
elements in the plaintext are rearranged. The fundamental requirement is that no information be
lost (that is, that all operations be reversible). Most systems, referred to as product systems,
involve multiple stages of substitutions and transpositions.
41

2. The number of keys used. If both sender and receiver use the same key, the system is referred
to as symmetric, single-key, secret-key, or conventional encryption. If the sender and receiver
each use a different key, the system is referred to as asymmetric, two-key, or public-key
encryption.
3. The way in which the plaintext is processed. A block cipher processes the input one block of
elements at a time, producing an output block for each input block. A stream cipher processes the
input elements continuously, producing output one element at a time, as it goes along.

2.12.2 Feistel Cipher Structure:

Many symmetric block encryption algorithms, including DES, have a structure first
described by Horst Feistel of IBM in 1973 [FEIS73] and shown in Figure 2.12.2.3. The inputs to
the encryption algorithm are a plaintext block of length 2w bits and a key K. The plaintext block
is divided into two halves, LE0 and RE0. The two halves of the data pass through n rounds of
processing and then combine to produce the ciphertext block. Each round i has as inputs LEi 1
and REi 1 derived from the previous round, as well as a subkey Ki derived from the overall K. In
general, the subkeys Ki are different from K and from each other and are generated from the key
by a subkey generation algorithm. In Figure 2.12.3, 16 rounds are used, although any number of
rounds could be implemented. The right-hand side of Figure 2.12.3 shows the decryption process.

Fig: 2.12.22 Average Time Required For Exhaustive Search

42

Fig: 2.12.2.3 Feistel Encryption and Decryption

All rounds have the same structure. A substitution is performed on the left half of the data.
This is done by applying a round function F to the right half of the data and then taking the
exclusive-OR (XOR) of the output of that function and the left half of the data. The round
function has the same general structure for each round but is parameterized by the round subkey
Ki. Following this substitution, a permutation is performed that consists of the interchange of the
two halves of the data.
The Feistel structure is a particular example of the more general structure used by all
symmetric block ciphers. In general, a symmetric block cipher consists of a sequence of rounds,
with each round performing substitutions and permutations conditioned by a secret key value.
The exact realization of a symmetric block cipher depends on the choice of the following
parameters and design features.
Block size: Larger block sizes mean greater security (all other things being equal) but reduced
encryption/decryption speed. A block size of 128 bits is a reasonable trade off and is nearly
universal among recent block cipher designs.

43

 Key size: Larger key size means greater security but may decrease encryption/ decryption
speed. The most common key length in modern algorithms is 128 bits.
Number of rounds: The essence of a symmetric block cipher is that a single round offers
inadequate security but that multiple rounds offer increasing security. A typical size is 16 rounds.
Sub key generation algorithm: Greater complexity in this algorithm should lead to greater
difficulty of cryptanalysis.
Round function: Again, greater complexity generally means greater resistance to cryptanalysis.
There are two other considerations in the design of a symmetric block cipher:
Fast software encryption/decryption: In many cases, encryption is embedded in applications
or utility functions in such a way as to preclude a hardware implementation. Accordingly, the
speed of execution of the algorithm becomes a concern.
Ease of analysis: Although we would like to make our algorithm as difficult as possible to
cryptanalyze, there is great benefit in making the algorithm easy to analyze. That is, if the
algorithm can be concisely and clearly explained, it is easier to analyze that algorithm for
cryptanalytic vulnerabilities and therefore develop a higher level of assurance as to its strength.
DES, for example, does not have an easily analyzed functionality.
Decryption with a symmetric block cipher is essentially the same as the encryption
process. The rule is as follows: Use the cipher text as input to the algorithm, but use the subkeys
Ki in reverse order. That is, use Kn in the first round, Kn 1 in the second round, and so on until
K1 is used in the last round. This is a nice feature, because it means we need not implement two
different algorithmsone for encryption and one for decryption.

44

3. Flat
3.1 Regular grammars:
Recall the general form of regular expressions:
If A is an alphabet, and a A , then a is a regular expression.
is a regular expression.
If r and s are regular expressions, then the following are also regular
expressions: r* , r s = rs , r + s , and ( r )
And the general form of context-free grammars (CFG):
a set T of terminals (usually denoted with lowercase letters)
a set N of non-terminals (usually denoted with uppercase letters)
a unique start symbol S N
a set P of productions of the form A , where A N and (T+N)*
Recall also that CFGs allow for specifying a richer variety of languages than do regular
expressions.
What is the relationship between CFGs and regular expressions?
Can regular expressions be rewritten as context-free grammars?
The answer is yes, but to see it, lets first considers a simpler type of CFG
Formally a grammar consists of a set of nonterminals (or variables) V, a set of
terminals
(the alphabet of the language), a start symbol S, which is a nonterminal, and a set of
rewrite rules (productions) P.
A production has in general the form a-> b, where a is a string of terminals and
nonterminals with atleast one non terminal in it and b is a string of terminals and nonterminals.
A grammar is regular if and only if a is a single nonterminal and b is a single terminal or a
single terminal followed by a single nonterminal, that is a production is of the form X -> a or X
-> aY, where X and Y are nonterminals and a is a terminal.
In theoretical computer science and formal language theory, a regular grammar is
a formal grammar that is right-regular or left-regular. Every regular grammar describes a regular
language.

45

3.1.1 Right linear grammar:

Regular languages are also generated by a rule formalism called Right (or Left) Linear
Grammar (also called type 3 Grammar): A -> aB
1. A is a single symbol (corresponding to a state) called a non-terminal symbol
2. a corresponds to a lexical item
3. B is a single non-terminal symbol.
Formal definition of Right Linear Grammars:
A right linear grammar is a 4-tuple <T, N, S, R>, where:
1. N is a finite set of non-terminals
2. T is a finite set of terminals, including the empty string
3. S is the start symbol
4. R is a finite set of rewriting rules of the form A-> xB or A-> x, where A and B stand for nonterminals and x stands for a terminal.
Formal example:
G1 = <T, N, S, R>, where T = {a, b}, N = {S, A, B}, and

Right Linear Grammar for Language L and its non-deterministic FSA:

46

S -> detB
S -> detC
B -> adj B
B -> adjC
C -> nounD
D -> transitiveVerbE
E -> noun

Finite State Automata and Right Linear Grammar:

Every FSA has a corresponding right linear grammar and vice versa. That is, for every
FSA, there is an equivalent right linear grammar that accepts the same language, and vice versa.
Converting a right linear grammar to an equivalent FSA
1. S is the start state
2. Associate with each rule of the form A -> xB a transition in a FSA from state A to state B
reading x
3. Associate each rule of the form A -> x with a transition from state A reading x to a final state,
F.

47

Example: Representing G1 from previous section as FSA:

Converting a FSA to a right linear grammar:

1. The states of the FSA become non-terminals of the grammar, and the alphabet of the FSA
become terminals of the grammar.
2. q0 becomes the start symbol S.
3. For each transition (qi, x) = qj, we put in the grammar a rule qi -> xqj.
4. For each transition (qi, x) = qj, where qj is a final state, we add to the grammar the rule qi ->
x.
5. If the start state q0 is also an accept state, imagine that you have a nondeterministic
FSA, where (q0, ) =q0
Example:

3.1.2 Left linear grammar:

In Left-Linear grammars, all productions have the form:
ABx
or
48

A x
Where x is some string of terminals.
Here is an example of a left-linear grammar:
Grammar J:
S Aa
A Aab |
L(J) = (ab)na, where n0
There is a set of steps for reversing a left-linear grammar, turning it into a right-linear
one (we wont cover it, but you can look it up). Since right-linear grammars are regular, it follows
that left-linear grammars are also regular.
Thus, Regular Grammars produce Regular Languages and are equivalent in expressive
power to Regular Expressions, DFAs, and NFAs.

Conversion from left to right:

Let S denote the start symbol

Let A, B denote non-terminal symbols
Let p denote zero or more terminal symbols
Let denote the empty symbol

1) If the left linear grammar has a rule S p, then make that a rule in the right linear
grammar
2) If the left linear grammar has a rule A p, then add the following rule to the right linear
grammar:
S pA
3) If the left linear grammar has a rule B Ap, add the following rule to the right linear
grammar:
A pB
4) If the left linear grammar has a rule S Ap, then add the following rule to the right linear
grammar:
Ap

Ex:
49

S Aa
A ab
Then
S abA
Ex:
If the left linear grammar has this rule A p, then add the following rule to the right
linear grammar: S pA
S Aa
A ab
Then
S abA
Aa
Ex:
If the left linear grammar has S Ap, then add the following rule to the right linear
grammar: A p
S Aa
A ab
Then
S abA
Aa

3.2 Equivalence between regular grammar and FA:

The regular grammar characterize the reguler sets, in the sense that a language is regular
if and only if it has a left linear grammar and if and only if has right linear grammar.
These results are proved in the next two theorems.
Theorem 1: If L has a regular grammar, then L is a regular set.
Proof: First, Suppose L=L(G) for some right-Linear grammar G=(V,T,P,S).
We construct an NFA with -moves, M=(Q,T,.[S],{[ ]} that simulates derivations in G.
Q consist of the symbol [] such that is A or a suffix of some right hand side of
production in P.
50

We Denote by:
1. If A is a variable, then ([A], )={[]|A is production}
2. If a is in T and in T* U T* V, then ([a], a)={[]|.
Then an easy induction on the length of derivation or move sequence shows that ([S], w)
contains [] if and only if S * xA-> xy, where Ay is a Production and xy=w or if =S and
w=.
As [] is the unique final state , M accepts w if and only if S

xA -> w.

But since every derivation of a terminal string has at least one step, we see that M accepts
if and only if G generates w. Hence every Right Linear Grammar generates w regular sets.
Now, Let G=(V,T,P,S) be a left linear grammar. Let G=(V,T,P,S), where P consist of the
productions of G with right sides reversed , i.e., P={A|AR is in P}
If we reverse the productions of a Left Linear grammar we get a right linear grammar and
vice versa.
Thus G is right linear and it is easy to show that L(G)=L(G)R.
By the preceding paragraph, L(G) is regular set. But the regular sets are closed under
reversal, so L(G)R =L(G) is also regular set.

Example4.2: The NFA constructed by theorem from grammar is shown in fig.

Now consider grammar (2) if we reverse it production we get S01S|0.

The construction of theorem for this grammar yield the NFA of Fig(2).If we reverse the
edges of that NFA and exchange initial and final state, we get another NFA for 0(10)*
51

Fig Construction of NFA for 0(10)* from left linear grammar.

Theorem4.2: If L is a regular set, then L is generated by some left linear grammar and by
some right linear grammar.
ProoF: Let L=L(M) for DFA M=(Q,,,q0 ,F).
First suppose that q0 is not a final state.
Then L=L(G) for right linear grammar G=(Q, ,P, q0 ), where P consist of production
paq when ever (p,a)=q and also pa whenever (p,a) is final state.

q0

Then clearly (p,w)=q iff p * wq. If wa is accepted by M, Let (q0 ,w)=p, implying
wp. Also, (p,a) is final, so pa is production. Thus q0 *wa.

Conversly, let q0 *
x. Then x=wa, and q0
(q0 ,w)=p and (p,a) is final.

wp

->

wa for some state p. Then

Thus x is in L(M). Hence L(M)=L(G)=L.

Now Let q0 be in F, so is in L . We note that grammar G defined above generates
L{}. We may notify G by adding a new star symbol S with production Sq0|. The resulting
grammar is still right linear grammar and generates L.
To produce a Left linear grammar for L, start with NFA for L R and reverse the right sides
of all productions of the resulting right linear grammar.

52

Example4.3 Consider the DFA

In fig above we see a DFA for 0(10)*.

The right linear grammar from this DFA is
A0B|1D|0
B0D|1C
C0B|1D|0
D0D|ID
As D is useless we may eliminate it , obtaining grammar,
A0B|0
B1C
C0B|0

3.3 Context free grammar:

Language of palindromes: Lpal

A palindrome is a string that reads the same forward and backward
Ex: otto, madamimadam, 0110, 11011,
Lpal is not a regular language (can be proved by using the pumping lemma)
We consider _ = {0, 1}. There is a natural, recursive definition of when a string of 0 and 1
is in Lpal.
Basis: , 0 and 1 are palindromes
Induction: If w is a palindrome, so are 0w0 and 1w1. No string is palindrome of 0 and 1,
unless it follows from this basis and inductive rule.
53

A CFG is a formal notation for expressing such recursive definitions of languages

What is a grammar?

A grammar consists of one or more variables that represent classes of strings (i.e.,
languages)
There are rules that say how the strings in each class are constructed. The construction can
use :
1. symbols of the alphabet
2. Strings that are already known to be in one of the classes
3. or both

A grammar of palindromes:

In the example of palindromes, we need one variable P which represents the set of
palindromes; i.e., the class of strings forming the language Lpal
Rules:
P
P0
P1
P 0P0
P 1P1
The first three rules form the basis.
They tell us that the class of palindromes includes the strings , 0 and 1
None of the right sides of these rules contains a variable, which is why they form a
basis for the definition
The last two rules form the inductive part of the definition.
For instance, rule 4 says that if we take any string w from the class P, then 0w0 is also in
class P.

Definition of context free grammar:

A GFG (or just a grammar) G is a tuple G = (V, T, P, S) where
V is the (finite) set of variables (or nonterminals or syntactic categories). Each variable
represents a language, i.e., a set of strings
T is a finite set of terminals, i.e., the symbols that form the strings of the language being
defined
P is a set of production rules that represent the recursive definition of the language.
S is the start symbol that represents the language being defined. Other variables represent
auxiliary classes of strings that are used to help define the language of the start symbol.

54

Production rules:
Each production rule consists of:
A variable that is being (partially) defined by the production. This variable is often called
the head of the production.
The production symbol!.
A string of zero or more terminals and variables. This string, called the body of the
production, represents one way to form strings in the language of the variable of the
head.
In doing so, we leave terminals unchanged and substitute for each variable of the body
any string that is known to be in the language of that variable

3.4 Derivation trees:

In a derivation tree, the root is the start variable, all internal nodes are labelled with
variables, while all leaves are labelled with terminals. The children of an internal node are
labelled from left to right with the right-hand side of the production used.
Ex:
Recall the CFG for equal 0s and 1s:
S 0S1S | 1S0S |
The derivation for 011100 given earlier was left-most:
S =) 0S1S =) 01S =) 011S0S =) 0111S0S0S=) 01110S0S =) 011100S =) 011100
It is useful to display derivation as trees. These pictures, called derivation (or Parse) tress.
The vertices of derivation trees are labeled with terminal or variables symbols of the grammar or
possibly with.
If an interior vertex n is labeled A, and the sons of n are labeled
X1 ,X2 , .Xk
from the left , then AX1X2Xk must be production.
It Shows the parse tree for derivation (id+id)*id. If we read the leaves in left to right order
, we get last line (id+id)*id.
EE+E|E*E|(E)|id
E

E*E

(E)*E

(E+E)*E

(id+E)*E

55

(id+id)*E

(id+id)*id

Example of derivation tree:

Here is derivation tree for 011100 in the above grammar:

The derivation tree for 1+23:

Note that derivation tree automatically knows that multiplication takes precedence over addition.

3.5 Sentential forms:

Let G = (V, T, P, S) be a CFG, and 2 (V U T)*.
If
We say is a sentential form.
If
we say that is a left-sentential form, and if S)rm we say that is a
right-sentential form.
Note: L (G) is those sentential forms that are in T*.
Ex:
56

3.6 Left most and Right most derivation of strings:

Leftmost derivation corresponding to the Tree
S

aAS

aSbAS

aabAS

aabbaS

aabbaa

Rightmost Derivation:
S

aAS

aAa

aSbAa

aSbbaa

aabbaa

Now consider the grammar

G = ({S, A, B, C}, {a, b, c}, S, P)
where
P = {S

ABC, A

aA, A

,B

bB, B

,C

cC, C

}.

With this grammar, there is a choice of variables to expand. Here is a sample derivation:
S

ABC

aABC

aABcC

aBcC

abBcC
57

abBc

abbBc

abbc

If we always expanded the leftmost variable first, we would have a leftmost derivation:
S

ABC

aABC

aBC

abBC

abbBC

abbC

abbcC

abbc

Conversely, if we always expanded the rightmost variable first, we would have a rightmost
derivation:
S

ABC

ABcC

ABc

AbBc

AbbBc

Abbc

aAbbc

abbc

There are two things to notice here:

1. Different derivations result in quite different sentential forms, but
2. For a context-free grammar, it really doesn't make much difference in what order we
expand the variables.

58