Nowadays, approximately all the software developers for commercial software developed software to meet the market requirements but unfortunately the security is always a secondary concern. Primary goal of software is to provide functionalities or services but managing associated risks is a secondary concern. There is often a trade-off/conflict between the security, and the functionality and convenience.
According to the text, the security in commercial software is distasteful. There are many vulnerabilities and actual attacks, scrambling among developers to fix and release patches, and continual exhortations to customers to perform rudimentary checks and maintenance. Software developer needs to find an effective solution to meet the customer explicit requirements and also include the implicit requirements in commercial software development but all that will also affect the cost and the development time.
Explicit requirements - software providers should deliver exactly what the customers’ time-to-market needs.
Implicit requirements - automatically include as a matter of professional duty but not always considered. Adding those requirements for both customer’s and providers benefits could be powerful.
Implicit Requirements Can Still Be Powerful
This chapter provides three different examples that approve the powerful of the including the implicit requirements. These examples are: Buying the hamburger from McDonalds, Buying a book from Amazon, and buying a software Application.
The implicit requirements for buying a hamburger - the hamburger is should pipe hot.
The implicit requirements for buying a book – the book should not miss any page.
The implicit requirements for a software application - a software application should meet the customer needs.
How One Firm Came to Demand Secure Software
According to the text, software security is more than identifying and removing defects in software code.
Over 50% of software vulnerabilities are based on defects in the architecture, not the code itself.
Identifying and addressing software defects early in the lifecycle is far more cost effective than fixing defects once the code is in production.
Encouraging software developers to think of security vulnerabilities as defects would be a significant challenge, requiring both a comprehensive education program and organizational development techniques for managing behavior change.
How I Put a Security Plan in Place
Choosing a focus and winning over management
It is very hard to fix everything at once.
The developers have to choose one area of software and focus on and strive for measurable improvements in security there.
The concentration of vulnerabilities in modern software makes the choice easy, as it is also consistent with the highest risk exposure.
Recent trends in security threat data clearly show the migration of hacker exploits away from network perimeters (routers, switches, firewalls, etc.) to the web application layer. Web applications are targeted because this area is the most economical approach to data compromise.
Setting up formal quality processes for security
- Integrated security within software could be very costly but of course it depends on what kind of security wants to be integrated and the how many levels.
- Integrated security within software makes the software itself more complex software.
- First of all they should create a list of key deliverables from CLASP (Comprehensive, Lightweight Application Security Process), a methodology for developing secure software developed by John Viega and adopted by OWASP.
- The security requirement need to be documented to helped define the application’s security requirements based on the classification of the data it handled
- The next step is making an intensive review o approve the architecture before development could proceed to the next phase.
- We have to choose the appropriate tool to verify the software before it goes to the quality assurance. A key criterion when we selected the tool was its high-quality contextual help, allowing relatively untrained developers to easily identify and understand security vulnerabilities.
Developer training
Encouraging the software developers to adopt and use the static analysis tool in the development process.
Security team should take a special educational program to teach them about security. Once the pass, they should teach their peers.
When the security process really took hold
After finishing the security education, the developers were willing to challenge the need for a static code analysis tool.
Fixing the Problems
Fixing any problem with the software may need time and more money. The developers should make and good schedule and milestone and stuck with it.
The developers’ team may discover the security flaws during the development process. Some of the security flaws are discovered during the testing the verifying process.
The developer team should early identify the vulnerabilities to minimize the actual cost.
The experience gained from the training and from pervious design process should be documented and could be used for the future software development and that would absolutely minimize the time and money.
Microsoft Leading the Way
Microsoft is one of the few commercial software providers that addresses security in the software development process. They updating their software development lifecycle with security controls, and currently have one of the most mature sets of security controls within their development process today. Consumer perception of Microsoft products may be influenced by the relatively large number of patches released monthly, but the reality is that Microsoft has listened to customer needs for security and has made progress addressing these needs.
Some of the security requirements are:
• Patch management
• Anti-virus and anti-spyware software
• Operating system security patches
• Vulnerability scanning
• Disk encryption
• Multifactor authentication
No comments:
Post a Comment