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. 

Differentiate between transparent and nontransparent fragmentation?

A number of problems are encountered because of the size of the data packets. There is no ability in the data link layer by means of which it could handle these problems and so the bridges also don’t work here. 

The Ethernet also experiences a number of problems because of the following:

Ø  Different way in which the maximum packet size is defined.

Ø  Maximum packet size that can be handled by a router.

Ø  The maximum length slot that are used for transmission

Ø  Errors due to the packet length

Ø  Standards

The data packets can be fragmented in two ways namely:

1. Transparent and
2. Non – transparent

Both these ways can be followed based on a network by network basis. We can also say that no such end – to – end agreement exists based up on which it can be decided which process is to be used.

Transparent Fragmentation: 

- This type of fragmentation is followed when a packet is split in to smaller fragments by a router.

- These fragments are sent to the next router which does just the opposite i.e., it reassembles the fragments and combine them to form original packet. 

- Here, the next network does not come to know whether any fragmentation has taken place. 

- Transparency is maintained between the small packet networks when compared to the other subsequent networks.

- For example, transparent fragmentation is used by the ATM networks by means of some special hardware. 

- There are some issues with this type of fragmentation. 

- It puts some burden on the performance of the network since all the fragments have to be transmitted through the same gateway. 

- Also, sometimes the repeated fragmentation and reassembling has to be done for small packet network in series. 

- Whenever an over-sized packet reaches a router, it is broken up in to small fragments. 

- These fragments are transported to the next exit router. 

- The fragments are assembled by this exit router which then forwards them to the next router.

- Awareness regarding this fragmentation is not maintained for the subsequent networks. 

- For a single packet fragmentation is done many times before the destination is finally reached. 

- This of course consumes a lot of time because the repeated fragmentation and assembling has to be carried out. 

- Sometimes, it also presents the reason of corrupting the packet’s integrity.

Non-Transparent Fragmentation: 

- In this type, the packet is split in to fragments by one router. 

- But the difference is that these fragments are not reassembled until the fragments reach their destination. 

- They remain split till then. 

- Since in this type of fragmentation the fragments are assembled only at the destination host, the fragments can be routed independent of each other. 

- This type of fragmentation also experiences some problems such as header has to be carried by each of the fragments till they reach their destination. 

- Numbering has to be done for all the fragments so that no problem is experienced in reconstructing the data stream.

Whichever type of fragmentation we use, one thing has to be made sure which is that later we should be able to form the original packets using the fragments. This insists on having some type of labeling for the fragments. 

Segmentation is another name for the fragmentation. A packet is injected in to the data link layer by the IP layer but it is not responsible for reliable transmission of the packets. Some maximum value on the size of the packets is imposed by each layer for their reasons. For a large packet that travels through the network for which the MTU is small, fragmentation is very much needed. 

Where are artificial neural networks applied?

The artificial neural networks have been applied to a number of problems in diverse fields such as engineering, finance, medical, physics, medicine, and biology and so on. 

- All these applications are based on the fact that these neural networks can simulate the human brain capabilities. 

- They have found a potential use in classification and prediction problems. 

- These networks can be classified under the non-linear data driven self adaptive approaches. 

- They come handy as a powerful tool when the underlying data relationship is not known. 

- They find it easy to recognize and learn the patterns and can correlate between the input sets and the result values.

- Once the artificial neural networks have been trained, they can be used in the prediction of the outcomes of the data. 

- They can even work when the data is not clear i.e., when it is noisy and imprecise. 

- This is the reason why they prove to be an ideal tool for modeling the agricultural data which is often very complex. 

- Their adaptive nature is their most important feature.

- It is because of this feature that the models developed using ANN is quite appealing when the data is available but there is a lack of understanding of the problem.

- These networks are particularly useful in those areas where the statistical methods can be employed. 

- They have uses in various fields:

    1. Classification Problems:

a)   Identification of underwater sonar currents.

b)   Speech recognition

c)   Prediction of the secondary structure of proteins.

d)   Remote sensing

e)   Image classification

f)    Speech synthesis

g)   ECG/ EMG/ EEG classification

h)   Data mining

i)     Information retrieval

j)    Credit card application screening

2. Time series applications:

a)   Prediction of stock market performance

b)   ARIMA time – series models

c)   Machine robot/ control manipulation

d)   Financial, engineering and scientific time series forecasting

e)   Inverse modeling of vocal tract

3. Statistical Applications:

a)   Discriminant analysis

b)   Logistic regression

c)   Bayes analysis

d)   Multiple regression

4. Optimization:

a)   Multiprocessor scheduling

b)   Task assignment

c)   VLSI routing

5. Real world Applications:

a)   Credit scoring

b)   Precision direct mailing

6. Business Applications:

a)   Real estate appraisal

b)   Credit scoring: It is used for determining the approval of a load as per the applicant’s information.

c)   Inputs

d)   Outputs

7. Mining Applications

a)   Geo-chemical modeling using neural pattern recognition technology.

8. Medical Applications:

a) Hospital patient stay length prediction system: the CRTS/ QURI system was developed using a neural network for predicting the number of days a patient has to stay in hospital. The major benefit of this system was that money was saved and better patient care. This system required the following 7 inputs:

Ø  Diagnosis

Ø  Complications and comorbidity

Ø  Body systems involved

Ø  Procedure codes and relationships

Ø  General health indicators

Ø  Patient demographics

Ø  Admission category

9. Management Applications: Jury summoning prediction: a system was developed that could predict the number of jurors that were actually required. Two inputs were supplied: the type of case and judge number. The system is known to have saved around 70 million.
10. Marketing Application: A neural network was developed for improving the direct mailing response rate. This network selected those individuals who were likely to respond to the 2^nd mailing. 9 variables were given as the input. It saved around 35 % of the total mailing cost.
11. Energy cost prediction: A neural network was developed that could predict the price of natural gas for the next month. It achieved an accuracy of 97%. 

Ensuring that there are clear agreements over deliveries from third parties

In today's world of software development, most large products use input components from a variety of sources. So, if you are building a new version of a video editing application, it tends to incorporate a large number of external components - some of these dealing with the ability of read views of different formats and codecs, then there will be the components dealing with burning what you created to a disc for which there are additional components, and so on. In all such cases, it always makes sense to use components that have a specialized function rather than try to build it yourself. In the current case, see how it difficult it would have been if you team was trying to write code to read the different video formats in existence today. You would have mostly given up trying to do such a thing. Even otherwise, there are other components that are used - if you are working for a company that has multiple applications, the company would ensure that common components are built at one place and included in the various application (this is the most efficient way of building such components); for example, you would be using a Help system, your application would be using Installers for installing the application onto the machine, you would have having a licensing system, you might be having a common system for generating the UI of the application, and so on.
Now, this sounds like  the most efficient way of building such an application. However, for somebody who has been there and done that, there are many slips between getting a robust system in place that integrates all these components in your schedule. For example, one of the biggest problems that we used to run into was the quality level of these components. We had a contract with one of our component makers who would supply us a component (and they used to supply the same component to our rivals and other applications in the video space). From time to time, we would run into problems where these components would not be delivered in time, or where we would have to reject the quality level of the component, because we found a critical bug.
Why were all these problems happening ? I am talking about a situation which used to happen a few years back, and it was extremely frustrating. However, it turned out that we had been working with them for many years, and we had never really tried to set some kind of process for these deliveries of the component and hence all the problems. So, we started out by working the timelines for when we need these components, and then did more analysis while working with the development and testing teams about the level of testing that we expected from the vendor end. Now, all this was being done from our end, and we had only aired some level of frustration with the vendor, but never really got in a problem solving discussion.
We set up a series of meetings with the vendor, talking them through what the current system was, pointed out the problems it was causing for us (and for them as well, since when we rejected a version of the component, it would have meant more effort from their end as well). We talked them through some of the solutions that we were looking at, we got our development and testing teams to have discussions with their respective teams on a regular basis. Now, this was not a magic bullet; they did not do everything that we had asked for, and in some cases, it meant that we had to pay around 10% more because of the extra effort on their side. However, in the end, we had a more strict agreement for the delivery of the component along with a quality level, and this allowed up stability in a part of our schedule, which was well worth it. 

Is there any problem in using scripts created on v6.0 to 6.5 or higher versions?

In some cases, it may happen that while trying to automate a java swing application using an early version of silk test such as the silk test 5.0.3. You found that the objects and controls in the application window of the application under test or AUT might not be recognizable by the silk test. 

This is just an example of problems of such category and at times you may wonder if the higher versions such as the silk test v 6.0 or silk test v 6.5 are suitable for automating your application or not? Or does the silk test comes with some extensions or add – ons as an alternate for overcoming such situations. 

The version 6.0 of the silk test is known to have some bugs in it, however, the Segue software has known to resolve these known issues. Actually, advancing form a lower version to a higher version of the silk test must not pose a problem. 

Though this is a general statement that we made on the basis of observation of several instances, it is not necessary that it should turn out to be true in all the cases. You may face some problems with the scripts that will work on an earlier but not on higher versions such as 6.0 and above because the object recognition patterns in both of them are not the same and vary from version to version. 

There are certain situations where the two paths of the script might be used for performing the same action but based up on the version. 

The silk test version 6.0 and silk test version 6.5 are somewhat similar and though no problems are experienced in advancing from version 6.0 to version 6.5 of the silk test. 

The various client forms of silk test are available such as those stated below:

1. Silk test classic: This client of the silk test makes use of the domain specific language called “4test” for scripting of the test automation scripts. This language just like the C++ language is an object oriented language. Just like C++ it also makes use of the Object Oriented concepts such as following:

a)   Inheritance

b)   Classes and

c)   objects

2. Silk 4J: This client of the silk test enables one to follow test automation by using java as the scripting language in eclipse.
3. Silk 4 net: This client of the silk test also enables one to follow test automation by using VBScript or sometimes using C# as the scripting language in the visual studio.
4. Silk test work bench: This client of the silk test enables the testers to carry out the automation testing using VB.net as the scripting language as well as on a visual level.

Below stated is the list of the silk test versions that have been released till now:

1. Borland silk test 13- june 2012
2. Micro focus silk test 2011 – November 2011
3. Micro focus silk test 2010 R2 WS 2 – may 2011
4. Micro focus silk test 2010 R2 – December 2010
5. Micro focus silk test 2010 – july 2010
6. Silk test 2009 – august 12, 2009
7. Silk test 2008 SP1 – jusly 2008
8. Silk test 2008 – april 2008
9. Silk test 2006 R2 service pack 2 – September 2007
10. Silk test 2006 R 2 service pack 1 – june 2007
11. Silk test 2006 R2 – January 2007
12. Silk test 2006 – September 2006
13. Silk test 8.0 – may 2006
14. Silk test 7.6 – September 2005
15. Silk test 7.5 – june 2005
16. Silk test 7.1 – October 2004
17. Silk test 6.5 – November 2003
18. Silk test 6.0 – November 2002
19. Silk test 5.0.1 – September 1999
20. QA partner 4.0 – November 1996

What are the types of web testing security problems?

Web testing is much in demand these days since the use of web sites and web applications are increasing by huge margins day by day. As the cyber crimes are increasing, web sites and web applications call for more security settings which in turn plunge in to the web testing schedule as the web testing security problems.

"Web testing is a kind of software testing that focuses on web sites and web applications. The security issues of the web sites and web applications are addressed by another type of web testing called web security testing". 

The testing of the web sites and web applications for security vulnerabilities is quite and exciting concept. Though the matter is quite exciting, it needs to be taken seriously. The best method to combat with the known web testing security problems can be to be prepared in advance and having knowledge of what is to be checked for.

In this article we are going to take up some of the most common security aspects that can pose problems in web testing. They are mentioned below:

1. Server problems: These are the most common security problem. It happens many a times that the server is down for maintenance or some other reason.
2. Hardware problems
3. Data base problems: Any problems in the data base of the web site or web application gives rise to many of the security problems. Any problem and uncertainty in the data base can prove to be a danger to the overall security of the web site or web application.
4. Navigation from one page to another: Too much of navigation from one page to another endangers the security of the web site or web application which in turn acts as a hindrance in the web testing of that particular web site or web application.
5. Server security: A server houses a web site or web application data base; therefore it is obvious that the security of the web site or the application relates a lot to the security of the server. Maintaining the security of the web server is quite an important point which otherwise could introduce many of the security problems during the web testing.
6. Authentication issue
7. Data encryption
8. User privileges leaks
9. SQL injection
10. Cross side scripting
11. Cookie testing
12. The content on a web site that proves to be inaccessible or incorrect can also pose security problems during web testing.
13. Improper validation of the input can disturb the working mechanism of the web site or web application.
14. Link testing is an important aspect of web testing. Broken links can hamper the security of the web site or application and thus poses problems in web testing security.
15. Incorrect copyright information.
16. Incorrect EULA or end user license agreement.
17. Un-optimized images that do not meet the specifications.
18. Improper storage of the data obtained through the web pages.
19. Time taken by the pages to render.
20. Lag in performance with many simultaneous users.
21. Concurrency issues like when a user is working on multiple windows of the same page or there are multiple users on the same page.
22. Improper and inefficient tracking of the transactions by the server log.
23. Improper usage of SSL by the web site or web application.
24. Inefficient working of the feeds.
25. Inefficient working of the cookies.

Web testing is absolutely essential if you want make sure that your web site or web application has enough browser support and the HTML is valid. 

What are common problems of test automation?

With the number of complex and advance applications increasing, the need for automation testing has also taken a strategic and critical point. In the past, the applications were quite simple and free of jargon. Assuming the level of testing to be sufficient at that time, how can we even think of testing today’s explosive software systems and applications with that level of software testing?

At this point of thinking, we come across two possibilities out of which first one is to increase the working staff and second one is to increase the level of testing. Following the first possibility seems like a bit ambiguous because the number of skilled testers is often less. So we are left with the second possibility. 

Over the years the testing has advanced and today we have what is called test automation process by virtue of which so many manual testing processes have been automated and precious human time has been saved. But this process too is not free of faults and problems. In this article we have focussed up on the common problems of the test automation.

Common Problems of Test Automation

- If you see the past cases you will come to know that the test automation did not reached the level of success at which it is today in one go itself, rather it faced many failures in the beginning. 

- So many test automation efforts were born which eventually died because of lack of efficiency in them. 

The First Problem:

- With test automation process, the vendors who develop and sell test automation tools do not provide any instantaneous demonstrations of the working of their tool and the simplicity and efficiency of the tools cannot be rightly judged. 

- What we see are some of the software systems and applications that the vendor has and up on which the testing tools work quite efficiently and think those tools will work in the same way for our applications also. 

- Consequently, what happens is that after doing many projects also we do not achieve same level of success. 

But we cannot blame the testing tools for the whole thing. 

- One possibility is also that the elements present in our software system or application might not be compatible with the testing tools that we are employing to test them.

- The only way to escape such pitfalls is that we try to develop some creative solutions using which we can make our software systems and applications compatible with the testing tools.

- This is perhaps the only way to make the testing tools work with our software systems and applications.

- There are so many commercial testing tools available that are marketed as solutions for testing the software products instead of being sold as solid aids for a wide test automation frame work. 

- One thing is common among all the software testing tools which is that they all contain one or the other scripting language that allows us to discover each tool’s failings. 

The Second Problem:

- Another problem with automation testing is that the testers carrying out the automation are not having any high development experience nor do they have been given ample training to exploit these testing processes and programming environments. 

- The automation testing requires both programming skills and testing skills, but what we have are only testers i.e., the testers who are not programmers. 

- Therefore for test automation to be effective, it is necessary that they should be expert in both testing as well as in programming. 

- Due to a lack of experience, the developers often make a simple solution far too complex to be maintained and implemented. 

What are different characteristics of smoke testing?

Smoke testing is considered to be one of the preliminary software testing techniques to further testing that are intended to reveal simple failures that are simple enough to be a cause of a software project to be rejected. 

In the term “smoke testing”, smoke is used as a metaphor. All the test cases that are known to provide coverage to most important functionality of a component of the software system or application are selected and grouped under a set and later are run. This is basically done to ascertain that the most crucial functions and features of the software system and application are working as desired or not! 

One can understand smoke testing better by having a look at the below mentioned questions:

1. Does the program run?
2. Does clicking the start button do anything?
3. Does the program run?

Goals of Smoke Testing

- The primary goal of the smoke testing is to determine if the problem or fault in the software system or application is so worse that any further testing on that software system or application will be a waste. 

- To put it simply, the smoke testing can be considered to be a cheap and less time consuming way to broadly cover the features and functionalities of the software product in a limited period of time. 

- By carrying out smoke testing, you can easily find out if any of your software system’s or application’s key feature or functionality is broken at some point and so your development team would not spend further time on it fixing or recreating it. 

People often confuse between the two similar terms i.e., smoke testing and build verification test. No doubt both are one and same the only thing when the smoke testing is performed on a build it called build verification test.

When should smoke testing be performed?

- One of the best practices of software testing is that the smoke testing should be performed everyday without fail. 

- Furthermore, the smoke testing can also be performed by the testers before accepting a module or build for further testing.

- Some testing has been listed as the most cost effective method for the identification and fixation of the defects in a software system or application after the code reviews by the software giant Microsoft Corporation. 

- The smoke testing is deployed as a process for the validation of the changes that have to be in the code before they are passed on to the source control in the Microsoft Corporation. 

- The smoke testing has to be carried out either automatically or manually that is purely the choice of the tester.

- When the smoke testing is carried out manually, the process goes on normally but when the automated tools are used, the tests that have to be carried out are initiated during the same process through which the build is generated. 

Smoke tests have 2 types as mentioned below:

1. Unit tests: Smoke tests under this category are known to exercise the sub routines, object methods and individual functions and so on.
2. Functional tests: These types of smoke tests are known to exercise the complete program along with various inputs.

Both the above mentioned type of smoke testing tools together make up a third party product that falls out of the compiler suite. 

A scripted series of program inputs form a function test and some may also have an automated mechanism. On the other hand the unit tests may be formed out of the separate functions that lie within the code. They can even be a driver layer that might be linked to the code. The smoke testing in software can be compared to the smoke testing in hard wares.