What are the security problems faced by a network?

Making mistakes concerning the network security is very common. The same mistakes are repeated again and again. These problems cannot be solved without changing our working methods. In this article we discuss about some common security problems that are faced by a network.

ØUsing weak and non-complex passwords for accessing the network: 

- Brute forcing is an old school exploit to which many of the system network administrators are open to. 

- The very famous captcha technology has been implemented for correcting this vulnerability of the network security passwords. 

- In the common captcha, the user is required to type in the digits or the letters that are displayed on the screen in some sort of distorted image. 

- This technology has been designed to prevent the network to be accessed by unwanted internet bots.

- However, this is not as safe as it looks. 

- It just gives a false sense to the network admins for countering the brute forcing. 

- Complex password is the solution for this problem. 

- For creating a complex password, more than seven characters need to be combined with special characters and numbers. 

- Apart from the creation of the complex passwords, a password expiration system has to be implemented. 

- This system is for reminding the users for changing their passwords. 

- Also, care should be taken regarding the reuse of the passwords. 

- Cycling of the passwords should not be allowed.

Ø Using server application or software that is outdated: 

- The patches are released by the companies from time to time for ensuring that the system does not become vulnerable to the various threats. 

- Also, new exploits and threats are posed by the hackers that can harm the network if the patches are not properly used. 

- For ensuring the network administrator is kept informed of the new threats, the software or the applications have to be updated regularly.  

Ø Web cookies: 

- Even though the viruses and malware cannot be introduced in to the network through cookies, these cookies can be tracked by some third party cookies for compiling the records of the browsing histories of the individuals. 

- The cookies that are not encrypted pose a major threat because they make the system vulnerable to the cross site scripting (XSS) attacks, thus putting your privacy at risk. 

- The open cookies can provide access to the cookies with the log-in data which can be used by hackers for intruding in to your systems. 

- The solution to this problem is to use the encrypted cookies along with an encoded expiration time. 

- The admins might ask the users to re-log-in before accessing important network directories.

Ø Plain hashes: 

- Hashing is the technique used for indexing and retrieval purposes in the database. 

- In most of the encryption algorithms, the plain hashes are mostly used. 

- A type of encryption is the salt that might be added to the hashes for making the creation of a look-up table that might assist the brute force or directory attacks extremely difficult or let’s say almost impractical. 

- But this works only when large salt is used. 

- Usually a pre-computed look up table might not be used by the attacker in exploitation of the network. 

- This makes the network security system even more complex.

- So even if the attacker is able to break into your system, he won’t be able to access the information from the database. 

- The encryption key should be kept hidden.

Ø Shared web hosting: 

- This service is used by the websites that reside on one same server. 

- Each site is given its own partition. 

- This is economically feasible for most of the systems. 

- But here if the attacker breaches in to system of one website, he can get into other website’s security systems too. 

Working with external teams for getting them to resolve their defects

When we do our planning for the next release of the software, we normally consider a number of risks, seeking to define a risk database that tabulates various known issues that could cause problems to the schedule and the smooth progress of the project. One lesser known risk that sometimes does not make it to the list of known risks relates to defects with people who are outside the core development team. For example, you may have a component that is being used in the product, and there is a defect against that component. Such defects have a higher risk than defects that are with the core team, even if the defect is of the same severity. There are many reasons for these defects having a higher risk. Some of these are:
- The outside team may not follow the same schedule or the priority as the product team.
- In fact, supporting the product team may be a lower priority for the component team, since they may have been given a task of providing support to other teams. This can happen a lot in organizations where there are a number of teams, and a strategic product will get much more support. For example, if the MS Access team and the MS Office team report defects in a component used by both teams, who do you think will get the priority support. In such cases, there will need to be more discussions, escalations, and other such measures before there is support granted.
- There is a much higher degree of coordination and communication needed when interaction with a developer who is outside the core development team
- The same defect may be treated as expected behavior by another team that is using the same component. You may be having a doubt about why a defect can be treated as a feature, but in some cases, a particular workflow behavior may be seen as a defect by one team, and desired behavior by another team. In such cases, the situation may be such that the defect may never be fixed.
- When the defect is with a component that is an open source component similar, there is no guarantee that such a defect may be fixed.

Given some of these reasons above, defects with developers who are outside the core development team are a much higher risk than most teams tend to visualize. We once had a hair raising case where the component we were integrating had a defect, but somehow the developer working on it was not able to replicate the defect. This was close to an important pre-release milestone, and we needed to get some fixing done on this defect, but this back and forth discussion and coordination at a remote location meant that it took around 2 weeks to get the defect fixed and a new component integrated, and this was a big problem for us.
What do you do when you have such dependencies on extended teams ? Well, you can never really get away from the defects, but atleast have processes setup to reduce the time period and coordination cost for these defects. What should you do ?
- Have an understanding with the remote team about the level of testing at their end. If necessary, send them test cases and ask them to provide completed test cases before they provide the component. This helps in reducing the chances of defects passing through their end.
- Setup a process where they can received updated copies of your software so that they can test with such latest software
- Ensure that the external team totally understands your defect management system and processes and they have been provided permissions for the software.
- Have a protocol with them about exchanging information with them about defects and if there are queries on these defects
- Have a regular meeting with them, this help in ensuring that any issues from either end are resolved quickly
- Ensure that any serious defects are communicated to them at a higher priority. This also includes defects that need to be fixed on priority.
- Define an escalation matrix with them, so that if there are cases where you are dis-satisfied or need quick action, what is the process to follow.

All of these will not mean that you will not have external dependencies on defects with external team members, but the problems associated with these defects will be reduced.

Working with people who are not so responsive as developers or testers ..

It can really test the patience of a team when they work with people who do not seem to follow the same guidelines, processes and schedules as the rest of the team does. It seems a bit odd though. The schedule is the most important item of a software development project, with a lot of effort going towards determining whether the team is following the schedule or not, and if there are any slippages from the schedule, it can imperil the success of a project. If there are slippages of the schedule, then it would take a lot of effort from the project manager and other managers and senior members of the team to get the project back on track. In such a case, it seems strange that there can be members of the extended team who are not so committed to the schedule (actually, it is not right to say that they are not committed to the project, it is just that it can be a challenge to get them to follow the details of the schedule).
Who are these members of the extended team ? Well, let me lay out a few candidates (and this does not mean that every one of these roles will not follow the details of the schedule, but I do know many people who were in such roles with whom it was a challenge to get them to follow the schedule) - these are typically the more creative people of the team - in some cases, the Product Manager; in more cases, the UI Designer or the Experience Designer; and even in other cases, some of the more senior members of the development team.
Does this really happen ? Well, yes, it happens like this all the time. Let me layout some examples - during the course of a project schedule, there is an initial time period when the requirements need to be defined by the Product Manager (with a certain detail inherent in these requirements, a level of requirements that is enough for the workflow designer and the development team to do a certain level of estimation), and more often than not, unless I, as the Program Manager would do a lot of reminder to the Product Manager, there would always be some amount of delay, or the requirements that were available were not of enough detail. As a result, by a couple of cycles, we had actually started giving a buffer so that after all the urging, there would be time to do a couple of cycle of the requirements. Given that the Product Manager is also typically a senior person, we did not try any other method of ensuring that they finished their work by the scheduled time; instead we added a buffer of around a week in the overall schedule.
The bigger problem was when we were dealing with the experience designer / UI designer. The interaction with this person was on a regular basis, for more than 70% of features (given that most of the features needed some kind of UI work, or needing some kind of workflow optimization). Hence, it was not only the overall schedule, but also the schedule for each feature that needed dates and details for work supposed to be done by the UI designer. The work done by the designer followed in a logical order to the requirements and was needed for the development team to do their work, and hence any delays in this work would cause a ripple effect all down the schedule. However, in a clear case of Murphy's Law, the chances of there being a delay from the designer end was high (not always, but in most cases, there would be something pending).
How do you ensure that the work done by the designer was on time ? Well, there are no clear ways (atleast nothing that was 100% successful), but here are some steps:
- Layout a clear schedule for when the delivery from the designer is expected, including dates for interim deliveries, review times, and final deliveries.
- If the designer does not agree with the dates that you would have started out with, and considers them too aggressive, then you need to do a discussion. Don't try to force any dates on the designer from your end, make sure that dates are negotiated.
- Setup a weekly telecon with the designer, and make sure that you are reminding them of the dates that are due, and also find out from them whether they are on track or not. If wildly out of track, then you might need to modify your dates to some degree, and make sure that the team knows about.
- If there is a manager from the designer end who is looking at this, then make sure that they are also in the loop for the work done.
- Finally cross your fingers and hope that this is not the schedule where the designer is going to delay their deliveries.

Dealing with dependencies that can impact your project schedule ..

Dependencies are the bane of a project schedule, or as one of the developers in a team told me, dependencies and other risks are the reason that a team needs a Project or a Program Manager. I have had informal discussions with some of the senior members of the team, as well as the members of the management team, and there is a lot of discomfort in handling the various dependencies that bedevil a project; as well as doing all the negotiations that are required to mitigate the risk of a dependency, or when the dependency causes a problem to the project.
What am I talking about ? Well, consider the fact that in today's world, most projects have a lot of dependency on items outside the control of the core team. You may be getting some work done from outside the core team by an external team, you may be picking up a component that has been created by an external team (which can be somebody who you pay for delivering the component, or you may be picking up a component that is being done by a open source type of team which produces a component and you pick up the component as and when it is prepared).
However, anytime you are using an external component, you are exposing yourself to a dependency and to a high amount of risk (actually the risks depends to the extent on which the dependency can screw your project). Let me list down a few examples:
- You use a component that is fairly stable (say, being done from another team in your organization). The component is fairly stable, and even though new versions of the component are released from time to time, there is no major necessity of picking up a new version of the component. The dependency is there, but the risk is low and so the mitigation required is also low. Even if there is a problem with the latest version of the component, you can stay with the version that you already have.
- You use a component where there is a bug fix that is needed for solving a problem in your application. In such a case, the risk to your product or project schedule depends on the critical nature of the defect in your application. If the defect is critical to your application, then you have a high amount of dependency and need some mitigation plans. If the component has some problem, then you have to consider the impact on your project and have mitigation plans accordingly. If you are able to survive with the defect in your software, then you would not imperil your schedule if there is any problem in the delivery or the quality of the component.
- Now consider the case of a component that is critical to your product, or delivers a functionality that is critical to your component. For example, when you consider the Adobe Camera Raw and the products that incorporate it, one of the critical advantages that a new version of the Camera Raw provides is support for new Digital SLR's that have been released. So if you were releasing a new version of Photoshop or a new version of Lightroom, it is important for them to integrate the latest version of Adobe Camera Raw because of this support for new cameras. In such cases, if a component is delayed, it causes significant problems for the product schedule and needs a high degree of mitigation. In this case, the mitigation that is done by these products is by enabling this component to be updated later. However, the mitigation strategy for every such component or dependency may not be so easily solved, and the team needs to ensure that there is a lot of thought to how to mitigate these problems.

What are benefits of agile process improvement?

Agile methodologies that we have today are a resultant of the experiences gained from the real life projects that were undertaken by the leading software professionals. These professionals were thorough with the challenges and limitations imposed by the traditional development methodologies on various projects. 

- The agile process improvement directly addresses the issues of the traditional development methods both in terms of processes and philosophy behind it. 

- Agile process improvement provides a simple framework to the development teams suiting varying scenarios while focusing up on the fast delivery of the business values. 

- With all these benefits of the agile process improvements, the organizations have been able to reduce the associated overall risk with the development of the project. 

- The delivery of the initial business values is accelerated well by the agile process improvement. 

- This is achieved through a process of constant planning and feedback. 

- Agile process improvement ensures that the business values are maximized throughout the development process. 

- With the API’s iterative planning plus feedback loop, it becomes possible for teams to align the software process with the business needs as required. 

- Another major benefit of the agile process is that the software development process can adapt to the ever–changing requirements of the process and business. 

- By taking a measure and evaluation of the status based up on the amount of work and testing done, visibility can be obtained to a more accurate value. 

- The final result of the agile process improvement is a software system that is capable of addressing the customer requirements and the business in a much better way. 

- By following an agile process improvement program, not only just deployable, tested and working software can be delivered on an incremental basis but also increased visibility, adaptability and values are delivered earlier in the software development life cycle. 

- This proves to be a great thing in reducing the risk associated with the project. 

- There are a number of problems with the traditional development methods. 

- In a research it was found that the waterfall style development methodology was the major factor in the contribution of failure of the software. 

- Some other software could not meet the real needs. 

- They had the inability in dealing with the changing requirements and late integration. 

- All this has proven that the traditional development methods prove to be risky as well as a costly way for building software. 

- Thus the majority of the industry has turned towards agile development.

- There is a continuous feedback input from the customers and a face to face communication among all the stake holders. 

- The business needs associated with the agile process improvement are ever changing. 

- Organizations want quick results from what they invest. 

- They want their improvement programs to keep pace with these changing business needs. 

- The agile process improvement is composed of several mechanisms using which all this can be achieved. 

- Working iteratively lets you deliver the product before the deadline to the customer. 

- It lets you deliver only the things are actually required i.e., it does not let you waste your time on the un-required things. 

- Also, early and regular feedback from the customer lets you deliver the product with quality as desired by the customer.

- Agile projects are distributive in nature i.e., the work is divided among people. 

- Agile software development is still an immature process and there is a need for improving it for the betterment of the software industry. 

- Agile process improvement is one way to do this.

Explain Rational Unified Process (RUP)?

Rational Unified Process development framework was developed by a division of IBM known as the rational software corporation. Rational Software Corporation has been a part of IBM since the year of 2003. 

About Rational Unified Process

- Rational unified process is a single process that has a concrete prescription.

- It is a process frame work which is adaptable to a large extent and can be tailored by the organizations and development corporations as per their needs. - They can select the elements of the process that they want to be present in their development approach. 

- The rational unified process or RUP is a product that is used to process other products. 

- This product is built on a hyper linked base of knowledge consisting of detailed description about a lot of activities along with some sample artifacts.  - Rational unified process constitutes a part of the IBM’s RMC product or rational method composer.

- It is used for customizing the rational unified process. 

- All the companies combined their experiences and declared 6 best practices that are known to drive the rational unified process. 

- Those 6 best practices are:

1. Iterative development where the risk is taken as the primary iteration driver.
2. Management of the requirements.
3. Employment of an architecture based up on component.
4. Visual modelling of the software system or application.
5. Continuous verification of the quality.
6. Controlling of the changes.

- The above mentioned 6 best practices are followed by the rational’s field teams in order to assist the customers in improving the predictability as well as quality of the efforts that they put for the development of the software.

- The resulting rational unified frame work had the following three main strategic characteristics:

1. This process is tailor-able for the effective guidance of the development process.
2. Consists of tools that are used for the automation of the process.
3. Involves services that accelerate and make the adoption of both the tools and processes easy.

- Rational unified process came into existence on the acquiring of the objector y process in the year of 1996 that was written by Ivar Jacobson. 

- This original process consisted of the content from the following three things:

1. Object modelling technology or OMT from Jim Rumbaugh,
2. Booch approach by Grady Booch and
3. UML 1.0

- Later the year of 1997 saw the addition of the test discipline and requirements to the approach. 

- Below mentioned are the additions to the approach that were made subsequently after the year of 1997:

1. Year 1998 saw the addition of two new disciplines namely configuration and change management discipline and business modelling. Other things that were added included the following techniques:

a)   Performance testing

b)   UI design

c)   Data engineering

Further the rational unified process was updated to 1.1 version of the UML.

2. Year of 1999 saw the addition of the project management discipline and techniques that supported the real time development of the software. Also the rational unified was again updated to UML 1.3.
3. From year 2000 onwards most of modifications were centered around the adding tool mentors, adding techniques along with a basic guide containing step by step instructions up on how the rational tools are to be used and how the customization of the rational unified process can be automated using which customers could customize their own process and at the same time incorporating improvements in the following releases. 

What is Segue Testing Methodology?

Segue testing methodology as its name suggests has got its origin with the segue software corporation and this is what that we are going to discuss here. 

This testing methodology is comprised of the 6 major phases that have been discussed in detail below:

1. Planning phase: In this phase, the testing strategy is determined as well as the specific test requirements are defined.
2. Capturing phase: In this phase the GUI objects present in the application under test are classified based on some criteria and also a test frame work is created for the execution of the tests.
3. Creation phase: This phase involves the creation of the automated tests that are reusable as well. Several recording and programming techniques can be used for developing the test scripts using the 4test language of the segue software.
4. Run phase: In this phase certain specific tests are selected by the user and executed on the application under test or AUT.
5. Reporting phase: This phase involves the analyzation of the test results and generation of the defect reports.
6. Tracking phase: This phase involves the tracking of the defects in the application under testing  or AUT and performing the regression testing.

About Segue Testing Methodology

- The quest-con technologies is one of the members of the silk elite partner program of the segue software. 

- This partnership has resulted in the improved integrated automation software of the segue software with the quest assured which is the proprietary methodology of the quest-con  

- This has proved to be an effective one for the mitigation of the risk that is involved in this whole automating manual process. 

- Quest assured provides an environment for flexible development of the software.

- The technologies used by it are all based up on the best practices of the quality assurance.

- These are effectively integrated by the automation testing principles of the quest-con with the automation software solutions of the segue technology. 

- For ensuring that the segue tools and technology are utilized to the full potential, the strong knowledge of the quest-con’s manual testing process as well as its capability of automating the appropriate portions of the concerned process are used. 

- The segue testing actually emphasizes on the idea of the practical quality assurance.

- Thus, the implementation of the automation solutions becomes relatively easy and less messy as when compared with the existing culture of the corporate. 

- It is because of the segue testing technology that the software delivered by the segue software ensure accuracy as well as performance of the enterprise applications. 

- With the segue testing technology, comprehensive performance, scalability, verification solutions and monitoring all is possible. 

- Further, these qualities of the segue testing methodology make it even more reliable to be used in the fundamental business process and also provides the user with the most predictable outcomes.

- Segue testing technology has effectively helped the companies in reducing the risks involved with the software.

- It also helps in increasing the return investment that we find quite associated with the deployment status of the business applications. 

- This all makes the segue software a leading innovator in technology. 

One success example of the segue software is the silk test which is now its trade mark. 

- Since long the segue testing technology has been known to dedicate itself entirely to the quality optimization of the solutions. 

- Thus, the segue software today has overcome the various optimization challenges that are faced by the software testing world. 

- The segue testing technology is based up on a result oriented approach which results in the proper optimization of each and every step of the testing process. 

What factors are needed to prioritize themes?

Need of users is considered before planning for a project. To achieve the best combination of product features, schedule, and cost requires deliberate consideration of the cost and value of the user stories and themes.
We need to prioritize and this responsibility is shared among the whole team. Individual user stories or features are aggregated into themes. Stories and themes are then prioritized relative to one another for the purpose of creating a release plan.

There are four primary factors to be considered when prioritizing:
1. The financial value of having the features.
2. The cost of developing new features.
3. The amount and significance of learning and new knowledge created by developing the features.
4. The amount of risk removed by developing features.

1. Determine the Value of Theme
- Estimate the financial impact over a period of time.
- It can be difficult to estimate the financial return on theme.
- It usually involves estimating number of new sales, average value of sales and so on.

2. Determine the Cost of Developing new Features
- Estimating cost of a feature is a huge determinant in overall priority of a feature.
- The best way to reduce the cost of change is to implement a  feature as late as possible.
- The best time to add feature is when there is no more time to change.
- Themes seem worthwhile when viewed in terms of time they will take.
- It is important to keep in mind that time costs money.
- The best way to do this while prioritizing is to do a rough conversion of story points or ideal days into money.

3. Learning New Knowledge
The knowledge that a team develops can be classified in two areas:
Product Knowledge
- It is the knowledge about what will be developed.
- It includes knowledge about features that are included and the features that are not included.
- Better knowledge of product will help the team to make better decisions.

Project Knowledge
- It is the knowledge about how product will be created.
- It includes knowledge about technologies, skills of developers, functioning of team together etc.
- The other side of acquiring knowledge is reducing uncertainty.

4. Risk
- A risk is anything that has not happened yet but might happen. It would threaten or limit the success of the project.
- Types of risks involved in a project are : schedule risk, cost risk and functionality risk.
- Struggle exists between high risk and high-value features of a project.
- Each approach has its drawbacks and the only solution is to give neither risk nor value total supremacy when prioritizing.

All these factors are combined by thinking first of the value and cost of the theme. Doing so will sort the themes into an initial order. Themes can then be moved forward or back in this order based on the other factors.

What are different characteristics of agile planning?

Two critical areas in software engineering are:
1. Estimating
2. Planning.
They are difficult and error-prone. These activities cannot be avoided.

The purpose of planning is to find an optimal answer to the overall product development question of what to build. The answer incorporates features, resources and schedule. It is supported by a planning process that reduces risk, uncertainty, supports reliable decision making, establishes trust and conveys information.

Planning is an ongoing iterative approach. It is an effort to find an optimal solution to the overall product development question of "what should we build?"

A good planning process supports:
1. Reducing Risk
2. Reducing Uncertainty
3. Supporting better decision making
4. Establishing trust
5. Conveying Information

A good plan is one that is sufficiently reliable that it can be used as the basis for making decisions about the product and project.

What is Agile Planning?

- It is more focused on planning than the creation of plan.
- It encourages change, results in plans that are easily changed.
- It shifts the focus from plan to planning.
- It balances the effort and investment in planning with the knowledge that we will revise the plan throughout the project.
- As the user needs are discovered, our plans are affected and hence changes become necessary.
- Plan are needed that are easily changed. Therefore, planning becomes more important that the plan.
- Changing plan does not mean a change in date.
- Plan can be changed without changing the date by:
            1. dropping a feature.
            2. reducing scope of feature.
            3. adding more people in the project.
- Agile planning is spread more or less evenly across the duration of a project.