DEVTOME.COM HOSTING COSTS HAVE BEGUN TO EXCEED 115$ MONTHLY. THE ADMINISTRATION IS NO LONGER ABLE TO HANDLE THE COST WITHOUT ASSISTANCE DUE TO THE RISING COST. THIS HAS BEEN OCCURRING FOR ALMOST A YEAR, BUT WE HAVE BEEN HANDLING IT FROM OUR OWN POCKETS. HOWEVER, WITH LITERALLY NO DONATIONS FOR THE PAST 2+ YEARS IT HAS DEPLETED THE BUDGET IN SHORT ORDER WITH THE INCREASE IN ACTIVITY ON THE SITE IN THE PAST 6 MONTHS. OUR CPU USAGE HAS BECOME TOO HIGH TO REMAIN ON A REASONABLE COSTING PLAN THAT WE COULD MAINTAIN. IF YOU WOULD LIKE TO SUPPORT THE DEVTOME PROJECT AND KEEP THE SITE UP/ALIVE PLEASE DONATE (EVEN IF ITS A SATOSHI) TO OUR DEVCOIN 1M4PCuMXvpWX6LHPkBEf3LJ2z1boZv4EQa OR OUR BTC WALLET 16eqEcqfw4zHUh2znvMcmRzGVwCn7CJLxR TO ALLOW US TO AFFORD THE HOSTING.

THE DEVCOIN AND DEVTOME PROJECTS ARE BOTH VERY IMPORTANT TO THE COMMUNITY. PLEASE CONTRIBUTE TO ITS FURTHER SUCCESS FOR ANOTHER 5 OR MORE YEARS!

Abstract

Software testing is broken down into verification and validation phases. Verification is the process of determining if the application meets specifications whereas validation determines if the finished product fulfills it intended purpose. One of the most important checks within the testing process is that of software assurance. Software assurance peers deeper into the coding and structure of an application to determine if the code is reasonably free of defects that could render it vulnerable to both inside and outside attack vectors. A solid software assurance program can and should integrate within the Software Development Lifecycle. According to the Software Engineering Institute, 90 percent of reported security incidents result from exploits against defects in the design and code of software. Therefore, the process of software assurance should be vital to all software development teams and if possible, should be given a special attention in each iteration to ensure that the final application will not present a security flaw within a customer’s infrastructure.

Software Assurance Scope and Definition

Software assurance and security testing go hand in hand. The goal of both verifies that the finished software meets several criteria,

  • That the behavior of the software is both predictable and secure
  • That the software exposes no vulnerabilities or weaknesses
  • That error and exception handling routines enable it to maintain a secure state
  • That is satisfies all of its specific and implicit nonfunctional security requirements
  • That is does not violate and specified security restraints (Potter & McGraw, 2004).

It is important to note that the goal of security testing is not to eliminate all risk, rather to mitigate as much risk as possible. Due to zero day threats and attacks that can come against proprietary software, it is impossible to gauge all potential attack vectors and then in turn design a totally secure application. However, a development team whether they are working for a large organization or a small company can be held liable for damages caused by defective software if it is proven that due diligence was not performed in testing and verify a software’s potential security flaws. Thus, it is recommended that security testing follow a pattern of well defined steps, that potential defects are addressed and that concise documentation be written to avoid any issues in the delivery of the final product.

Implementing a Software Assurance Stance

The most important step to developing a solid software assurance program is to stress the point that software assurance should be everyone’s job. To relegate the duties of software security to one individual introduces a single point of failure and thus increases the risk that one or more defects might go unnoticed. Not only should software assurance directives extend laterally across the development team, it also needs to be common thread through all levels of management. This will lead to an instilling of a culture of security awareness with developers and managers. Developers and managers alike need to familiarize themselves with common exploits used on the language(s) used in the software project. Numerous resources both on the Internet and in print discuss vulnerabilities on a variety of different platforms and breaks down common exploits based on what programming language being used. Those same resources go into detail contrasting and comparing strongly typed languages such as Java and C# against weakly typed languages such as PHP. One specific publication that should be staple in a developer’s library is the SANS Top 25 Most Dangerous Programming Errors. This comprehensive listing details common programming, design and architecture errors that can lead to exploitable vulnerabilities. Even with appropriate resources and support of the chain of command, the team designing the software must remain vigilant at every aspect of the development process, not just at the end where defects may have been compounded due to being overlooked in previous iterations. It is also vital that the scope of the assurance testing be gauged based on the customer. Many government agencies define software assurance in different ways. In the same respect, many private organizations require that software products comply with strict government compliance standards. These requirements should be collected and documented when gathering customer requirements to ensure that they are included in every aspect of the design and development phases. Processes and documentation can then be developed that focus on security issues related to the project at hand.

Software Assurance Testing and the SDLC

As stated previously, software assurance testing needs to take place at various points in the development project as opposed to being relegated to the end of the project. This lends itself to detection of potential flaws before they compound into larger issues. Security testing can and should integrate within the software development life cycle no matter the project (Potter & McGraw, 2004)

Abuse Cases and Security Requirements

The first step in the Software Development Lifecycle is to gather user requirements. This defines the way in which the program needs to function and the output that needs to be produced. The requirements are then used to develop use cases. Use cases define an action upon an object or the way in which a particular user will interact with the software being developed. They are used to construct the functional requirements of the system. During this phase of development, it is recommended that subsequent abuse/misuse cases be developed. Whereas use cases detail legitimate actions on the system being created, abuse cases are used to detail how software should react to illegitimate use. Detailed abuse cases can present a clear picture of how a system could be exploited and leads itself to the implementation of features that prevent misuse. Abuse cases can also detail the security requirements of the client. These requirements can either be mandated by federal or state agencies or internal policy of the organization. Either way, failure to properly address unexpected or abnormal behavior can leave a potential attacker with many different attack vectors to the client’s infrastructure.

Risk Analysis

Risk analysis deals with the identifying system outputs, the criticality of those outputs and then determining a probability of those outputs being a risk to the organization. It should be noted though that risk analysis in software development is difficult and that it is impossible to gauge what all potential vulnerabilities could do to software application. The goal instead should be to mitigate as much risk as possible. The detail to which this is done is up to the software development team. A thorough review of the programming language being used and a ranking of exploits used against that language can be used at this point in the process to write secure code.

External code review

During the design phase, it is important to include an external review of the design and structure of the application. This should be conducted by a group that has not worked on the project and can provide an unbiased review of the customer requirements, use/abuse cases and risk analysis done to this point in the project. The external review will often point out flaws and defects that may have gone unnoticed by the group tasked with the development project.

Risk-based Security

Risk-based security tests are done at periodic intervals between the development of test plans and the start of formal coding. These tests comprise of formulating and executing abuse and misuse tests; which were gleaned from earlier cases; that attempt to exploit the weaknesses in the application. These tests also serve to discover symptomatic conditions that suggest the existence of other vulnerabilities.

Static Analysis

Static analysis tools are used at various phases in the coding process to further tighten the developing application’s security posture. A static analysis tool is an automated software package that dissects the source code being developed without actually executing the application being developed. The purpose of this is to once again test the software for any defects or common exploits based on the language being used to develop the application. Static analysis tools are available to for many different platforms and programming languages (Schilling, & Alam, 2006)

Final testing processes

It is during the testing phase of the software development life cycle that more detailed risk analysis is performed on the finished code. Penetration testing can be performed before and after the final application has been completed and can also be a final verifier of software assurance during the testing phase. As its name implies, penetration testing is the active attack of an executed software program. Abuse and misuse cases documented in the requirements phase of the SDLC can be used as attack vectors as well as utilizing the Top 25 list of software exploits by programming language published by SANs or other sources can simulate attacks from outside sources. Further security testing should be done after the application is delivered to the end user due to every environment having differences. This can be facilitated by allowing clients to have access to support staff who can escalate issues to developers and engineers as needed so that security patches can be developed in a timely manner. Testing should be ongoing and patching implemented during the lifecycle of the application.

Conclusions

Software assurance and security testing must be implemented and overlaid on the software development life cycle for every project both large and small. Failure to adopt, maintain and vigilantly adhere to security processes and documentation will result in software that is not only defective but could expose both the development team and their client base to severe legal repercussions due to the introduction of attack vectors. Assurance should be a goal of the entire project team both laterally in the developer population and within the chain of command to mitigate risks while developing quality software.

References

Software


QR Code
QR Code software_assurance (generated for current page)
 

Advertise with Anonymous Ads