Docstoc

Software Security Risk Mitigation with Historical Information

Document Sample
Software Security Risk Mitigation with Historical Information Powered By Docstoc
					International Journal of Application or Innovation in Engineering & Management (IJAIEM)
       Web Site: www.ijaiem.org Email: editor@ijaiem.org, editorijaiem@gmail.com
Volume 1, Issue 2, October 2012                                         ISSN 2319 - 4847


               Software Security Risk Mitigation with
                      Historical Information
                                           A.Sumithra1, Dr.E.Ramaraj2 and A.Saranya3
                                   1
                                   Research Scholar, Madurai Kamaraj University, Madurai,India.
                                       2
                                           Associate Professor, Alagappa University, Karaikudi, India.
                               3
                                M.E (CSE) Student , Fatima Michael Engineering College, Madurai

                                                                 Abstract
Engineering of Secure Software is increasingly becoming a challenge confronted by many Software Engineers and Managers
owing to the permeation of software into many areas. Every Software Project is fraught with risks and the principles pertaining
to the management of these risks are being studied by researchers. Security Risk is too important to be considered as just one of
the many risks faced by a Software Project due to the repercussions such Security Risks might have on the customer. This
paper proposes an approach for the management of Security Risks that relies on the historical information available to an
organization with regard to the security attacks on previous applications developed and delivered by it. The paper also analyzes
the improvement in the security of Software brought about by the adoption of the approach.
Keywords: Secure Software, Security Risk, Software Project, Management.

    1. INTRODUCTION
Risk Management is an integral part of management of any project and a Software Project is no exception. Infact, there
are many factors that render the management of a software project more difficult that other projects [3].
Every Software Project is fraught with many risks. These risks may relate to the costs, schedule, personnel and quality.
In the early decades of the software industry, out of the many risks posed by a software project, those relating to the
quality of the software being engineered were considered the most difficult to be dealt with and many researchers have
proposed techniques for the mitigation of risks relating to Quality. Some of these include, Reviews, Inspections, and
adoption of Software Quality Assurance (SQA).

    2. SECURITY AND SECURITY RISK
As long as Software was restricted to operate within a single machine and had limited users, security was a trivial issue
for Software Developers and Project Managers. But today, Software has permeated many areas that were not
contemplated in the earlier days. This can largely be attributed to the advent of Distributed Computing in general and
the World Wide Web in particular. As the usage arena of software extends into many sensitive areas like banking and
National Security, the Security of the Software has assumed tremendous importance owing to the disastrous
consequences that may be caused by security Compromises.
Some early attempts to deal with this problem, tried to include Security as one of a long list of Quality Characteristics
expected of any software. Thus security was placed in par with say, Reliability and Safety. But quickly the loopholes in
this approach became evident. If a Software fails to meet its stated functional requirements, there is always a chance to
fix the issue and issue a patch to the customer. And this might incur a little cost to the customer. But if the Software
fails to be secure, the loss incurred to the customer may be so large that it cannot be compensated for.
An example would clarify the distinction. Suppose there was a fault in a banking Software so that the software always
issued transaction details of a particular bank account for the past 3 months regardless of the dates specified by the
customer. Such a fault will result in customer complaints to the bank and the loss incurred to the bank will be a little
damage to its good will. But if the Software has a flaw that allows an attacker to transfer amounts from any account to
his account, the loss incurred will be huge.
Therefore, risks pertaining to the Security of a Software have increasing implications and have to be dealt with and
managed correctly. Security Risk Management for Software Projects is an active area of research and the outcomes of
such researchers can be of great help to Software Project Managers in managing the Security Risks posed by Software
Projects.




Volume 1, Issue 2, October 2012                                                                                       Page 10
International Journal of Application or Innovation in Engineering & Management (IJAIEM)
       Web Site: www.ijaiem.org Email: editor@ijaiem.org, editorijaiem@gmail.com
Volume 1, Issue 2, October 2012                                         ISSN 2319 - 4847

    3. SECURITY RISK MITIGATION THROUGH HISTORICAL INFORMATION AVAILABLE TO AN
        ORGANIZATION
An underlying assumption in Software Reliability is that the software is delivered to the customer with faults and once
the fault reveals itself to the customer, the customer reports the fault and appropriate fixes are applied. It is very
difficult to deliver a complete fault-free software regardless of the care a Software Project Manager takes for its
development and testing.
Taking a similar approach for Security, every Software is delivered to the customer with vulnerabilities that might be
exploited by attackers regardless of the care taken by a Project Manager to ensure that the delivered Software is Secure.
Once the customer reports the vulnerability, it is “patched”. But an organization need not repeat the same mistake
twice. A study shows that 80-90% of Security Attacks exploit common vulnerabilities [2]. So after an organization
comes to know about a Security Attack that exploited a vulnerability in the software, in addition to applying the fix for
the vulnerability, the organization can and should document the vulnerability exploited and the fix applied.
This historical information can be of vital help to the organization in preventing the same vulnerability that was
exploited in the previous project, from occurring in the current project. The Requirements Specification may be
augmented with new requirements pertaining to the vulnerability or Security Reviews can focus on the vulnerabilities.
The organization can even prioritize the vulnerabilities based on the damage caused by them to the customer and end
up with a checklist of vulnerabilities that ought to be removed from Software prior to delivery.
Very few Security Attacks are unique. For example, in the case of World Wide Web Applications, the most common
vulnerabilities exploited are presented in [1]. An organization that can learn from its past mistakes can definitely
deliver more secure Software in the future. Thus historical information pertaining to attacks on the past applications
delivered by an organization can be of extensive help in mitigating the Security Risk posed by the current Software
Project

    4. CASE STUDY
We attempted to study the potential of Historical Information pertaining to attacks on previous applications delivered
by an organization in mitigating the Security Risk of applications currently being developed. The study was conducted
in a local Software Organization in our town. The organization is involved in developing and maintaining web sites for
its customers. The organization is about 3 years developed and has previously delivered hundreds of web sites. The
organization was constantly battling with security related issues reported by their customers.
We encouraged the organization to maintain historical information pertaining to Security Attacks on their previous web
sites. The organization maintained this information for 3 of their previous web sites. When the organization started on
their venture of development of a new web site, they had built a checklist of the most common and high damage
potential vulnerabilities and used this information to focus the attention of the entire team (from Requirements Analysis
to Testing) to prevent these vulnerabilities from reoccurring in their current web site. As expected, this time the web
site the organization delivered, had fewer Security Attacks reported on it compared to the previous 3 web sites.

    5. RESULTS AND DISCUSSION
We call the previous 3 web sites the organization developed and collected historical information as W1, W2 and W3.
W4 denotes the current web site developed by the organization building on the knowledge acquired from attacks on
W1, W2 and W3. The Results are tabulated below:
                              Table 1: No of attacks reported on the Four Applications
      Application      No of Attacks Reported in No of Attacks reported in            No of Attacks reported
                       the first two months           the next two months             after First Four Months
      W1               7                              17                              12
      W2               4                              11                              9
      W3               9                              13                              16
      W4               2                              6                               4
                                20
                                15
                                10
                                 5                                                   W1
                                 0                                                   W2
                                         No of            No of         No of        W3
                                        Attacks          Attacks      Attacks        W4
                                      Reported in      reported in    reported
                                      the first two   the next two   after First
                                        months           months         Four


                         Figure 1: Comparison of the number of attacks in the 4 applications


Volume 1, Issue 2, October 2012                                                                                Page 11
International Journal of Application or Innovation in Engineering & Management (IJAIEM)
       Web Site: www.ijaiem.org Email: editor@ijaiem.org, editorijaiem@gmail.com
Volume 1, Issue 2, October 2012                                         ISSN 2319 - 4847

As can be observed from the results, application W4 which utilized the potential of the knowledge acquired from the
release of the previous 3 applications, reported a fewer attacks compared to the other three. Another interesting
observation is that the checklist of vulnerabilities built by the organization, based on the first 3 applications, contained
a lot of common vulnerabilities reported and studied extensively in the literature, while some of them had to do with the
design and coding practices of the organization. The Historical Information is useful in reducing the number of attacks
that arise from both the common and the not-so-common vulnerabilities.

    6. CONCLUSIONS AND FUTURE WORK
Historical Information pertaining to security attacks on previous applications delivered by the organization has
immense potential in mitigating the Security Risk posed by Software Projects. The claim was validated by an empirical
study conduced in a Web Site Development Organization.
The Historical information collected and used by the organization was largely unstructured. As a part of future work,
techniques for converting this to structured information can be of immense potential in automating some of the risk
mitigation strategies.

REFERENCES
  [1]       The      Open       Web        App       Security       Project,    Top-10      2010      –      Main,
    https://www.owasp.org/index.php/Top_10_2010_main
  [2] Neil Roster, Exploiting the Exploitable: New Software Vulnerabilities Down, but Risk remains high, Secunia
    Reports, Feb 21, 2012, www.securitybistro.com/blog/?p=1060
  [3] Hughes, Bob and Cotterell, Mike, “Software Project Management”, Forth Edition.
  [4] Yang J., Honavar V., Feature Subset Selection Using a Genetic Algorithm, IEEE Intelligent Systems, vol. 13,
    1998, pp 44-49.
  [5] Raymer M.L., Punch W.F., et. al., Dimensionality Reduction Using Genetic Algorithms, IEEE Trans. On
    Evolutionary Computation, Vol.4, 2000, pp 164-171.
  [6] Hochman R., Khoshgoftaar T.M., Allen A.B., Hudepohl J.P., Using the Genetic Algorithm to Build Neural
    Networks for Fault-Prone Module Detection, Proc. Of 7 th IEEE International Symposium on Software Reliability
    Engineering, New York, 1996, pp 152-162.
  [7] Liu Y., Khoshgoftaar T.M., Genetic Programming Model for Software Quality Classification, Proc. Of 6 th IEEE
    International Symposium on High Assurance Systems Engineering, 2001.
  [8] Duda C.D., Hart P.E., Stork D.G., Pattern Classification, Wiley & Sons, New York, USA, 2001.

AUTHOR

               A.Sumithra received the BE from Sethu Institute of Engineering. and M.Tech. degrees in Information Technology
               from Kalasalingam University in 2008 and 2010, respectively. At Present working in Velammal College Of
               Engineering and Technology.. Area of Interest are Software Engineering ,Software Requirement Engineering.




Volume 1, Issue 2, October 2012                                                                                  Page 12

				
DOCUMENT INFO
Description: International Journal of Application or Innovation in Engineering & Management (IJAIEM),Web Site: www.ijaiem.org Email: editor@ijaiem.org, editorijaiem@gmail.com