1. Software Engineering1.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 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 half-century. 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:

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 itcan 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.

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.

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. 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:

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):

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.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 quantitativelyunderstood and controlledusing 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.

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.

1.8 A Process Framework

Software process models can be prescriptive or agile, complex or simple, all-encompassing 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 processProcess frameworkUmbrella activitiesFramework activity #1Software Engineering action

Fig: 1.8.1 A Process FrameworkEach 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 stakeholders) and encompasses requirements gathering.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 processReusability 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 more-detailed 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) 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

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 Determine state of organizations software process Software Capability Evaluations 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:

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

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

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 productsPSP 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- Systems tests- Systems maintenance- Enhancement of large software systemsTeam 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 planBenefits: 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. TSP will help your organization establish a mature and disciplined engineering practice that produces secure, reliable software.

2. Network Security2.1 Security AttacksIntroduction: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 resourcesa) Traffic Analysisb) Release of message contentsa) 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.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:

Fig: 2.1.1 Types of Security Attacks

1. Interception2. Interruption3. Modification4. 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 parties has been overheard by someone else.

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:

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 ofsecurity-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) Confidentiality2) Authentication3) Integrity4) Non-repudiation5) Access Control6) 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 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.

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.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 mechanisms2.3.1. Specific security mechanisms:May be incorporated into the appropriate protocol layer in order to provide some of OSI security services1.1. Encipherment

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 keys1.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 forgery1.3. Access control

A variety of mechanisms that enforce access rights to resources1.4. Data integrity

A variety of mechanisms used to assure the integrity of a data unit or stream of data units1.5. Authentication exchangeA mechanism intended to ensure the identity of an entity by means of information exchange1.6. Traffic paddingThe insertion of bits into gaps in a data stream to frustrate traffic analysis attempts1.7. Routing controlEnables selection of a particular physically secure routes for certain data and allows routing changes, especially when a breach of security is suspected1.8. NotarizationThe use of the third trusted party to assure certain properties of a data exchange2.3.2 Pervasive security mechanisms:Mechanisms, not specific to any particular OSI security service or protocol layer1. 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:

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.

Fig: 2.4.1 Model for Internet SecurityA 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 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 ModelViruses 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

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.

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 asstrncpy(), 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 overflowsbufbecause, depending on the size off, 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 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 (DF)telnet.com.23 > tclient.net.39904: S 1192930639:1192930639(0) ack 733381830 win 1024 (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:

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:

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 datapackets traveling over anInternet Protocol (IP) network will be directed. All IP-enabled devices, includingrouters and switches, use routing tables.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 nexthopon its route across the network.

A basic routing table includes the following information: Destination: TheIP addressof 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-attachedsubnets, 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 routingprotocols to exchange information about the surrounding networktopology. 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):

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.

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

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.

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.

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 agrammarconsists 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 regularif and only ifais a single nonterminal andbis 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.

Intheoretical computer scienceandformal language theory, aregular grammaris aformal grammarthat is right-regular or left-regular. Every regular grammar describes a regular language.

3.1.1 Right linear grammar:

Regular languages are also generated by a rule formalism called Right (or Left) LinearGrammar (also called type 3 Grammar): A -> aB

1. A is a single symbol (corresponding to a state) called a non-terminal symbol2. a corresponds to a lexical item3. B is a single non-terminal symbol.

Formal definition of Right Linear Grammars:

A right linear grammar is a 4-tuple , where:

1. N is a finite set of non-terminals2. T is a finite set of terminals, including the empty string3. S is the start symbol4. R is a finite set of rewriting rules of the form A-> xB or A-> x, where A and B stand for non-terminals and x stands for a terminal.

Formal example:

G1 = , where T = {a, b}, N = {S, A, B}, and

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

S -> detBS -> detCB -> adj BB -> adjCC -> nounDD -> transitiveVerbEE -> 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 state2. Associate with each rule of the form A -> xB a transition in a FSA from state A to state B reading x3. Associate each rule of the form A -> x with a transition from state A reading x to a final state, F.

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 nondeterministicFSA, where (q0, ) =q0

Example:

3.1.2 Left linear grammar:

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

ABx or 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 grammar2) 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: A p

Ex:

S Aa A ab ThenS 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 ThenS abA A a

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 ThenS abA A a

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.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 t