In the previous two articles I discussed different vulnerabilities in the security products. In this article I will discuss how we can build secure products.

Secure Software Development is one of the most discussed topics today. This article will cover the various practices currently being followed in the industry. It will also discuss specific actionable steps which an organization can adopt to enhance the security of products being developed.

Various models have been developed to formalize the process of secure software development. SSE-CMM and Microsoft Secure SDL are two of such well known models.

SSE-CMM—Systems Security Engineering Capability Maturity Model: The SSE-CMM is a process model that can be used to improve and assess the security engineering capability of an organization. The SSE-CMM provides a comprehensive framework for evaluating security engineering practices against the generally accepted security engineering principles. By defining such a framework, the SSE-CMM, provides a way to measure and improve performance in the application of security engineering principles. The SSE-CMM is now ISO/IEC 21827 standard and version 3 is now available. Further information about the model is available at http://www.sse-cmm.org.

SSE-CMM has two broad areas:

• Security Engineering

• Project and Organizational processes

Security Engineering is broken into Engineering Processes, Assurance Processes, and Risk Processes. These are further divided into 22 Process Areas With its own set of goals and activities.

Microsoft’s Trustworthy Computing Security Development Lifecycle: Microsoft developed The Trustworthy Computing Security Development Lifecycle (or SDL) to enhance the security of the products. The process entails several activities in the requirement, design, implementation, and release phases. There are several activities like Threat Modeling, Fuzzing, and Code Review etc which are part of different phases.

Phases of Secure Product Development Lifecycle

The secure product development lifecycle can be broken up into five distinct phases

• Requirement Phase

• Design Phase

• Implementation Phase

• Testing and Verification Phase

• Maintenance Phase

Each of the phases is discussed in detail in the subsequent sections.

Phase 1: Requirement Phase

Security requirements should be captured at the very beginning of the requirement gathering. They should be driven by several factors including business needs, compliance/regulatory needs. Along with the functional and non functional needs we should also capture the needs of security risk assessment, means to address the identified risks etc. The requirements can be captured using use cases, customer inputs, best practices, legal/regulatory/compliance requirements, code integrity requirement, intellectual property protection needs, corporate information security policy etc. As a part of the rollout plan, a prioritization and release plan should be made, keeping in mind the security requirements.

Key Areas for Requirement Phase:

• Team Requirement and Background

• Authentication and Authorization Requirements

• Audit Logging

• Cryptography and Key Management

• Data Validation and Sanitization

• Network and Data Security Requirements

• Third Party Integration and Security Requirements

Phase 2: Design Phase

As a part of the design phase, software architects try to identify and define a mitigation strategy for the possible security threats. This process of defining security threats and a mitigation strategy is variously known as “Threat Modeling”, “Risk Analysis” etc. Understanding threats early in the product life cycle significantly increases security and reduces costs.

It is advisable to conduct a real in-depth threat modeling using the right tools and techniques to capture all possible (or at least as many as possible)threats during this phase. An incomplete job may actually turn out to be more costly.

For Web Applications, Microsoft proposes five step threat modeling process:

• Identify Security Objectives: Define objectives or goals for the activity.

• Survey the Application: Identify the different use cases and the actors/users along with the important characteristics of the application.

• Decompose the Application: The application should be broken down into critical functional entities for understanding threats and their implications better.

• Identify Threats: Threats are identified using several models like attack graphs. Classification models like STRIDE/DREAD etc are also used for web applications.

• Identify Vulnerabilities: Layers of the application are reviewed to identify weaknesses related to the identified threats.

There are several threat classification models for applications like STRIDE or DREAD. STRIDE is a classification scheme for characterizing known threats according to the kinds of exploit that are used. The STRIDE acronym is formed from the first letter of each of the following: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. The DREAD acronym is formed from the first letter of the following: Damage potential, Reproducibility, Exploitability, Affected users, Discoverability. There are other approaches like TRIKE, AS/NZS 4360:2004 Risk Management, OCTAVE etc which are also used for Risk Management.

Phase 3: Implementation Phase

Unsafe function calls are the reasons for the Buffer Overflow vulnerabilities. In case of C or C++ there are several functions like strcopy, strncpy, scanf, strcat, strncat, gets, sprint families which are vulnerable to buffer overflow. It is critical to train the developers on the usage and non-usage of function calls.

There are several compilers which can provide compile-time and run-time protection against buffer overflow. It is advisable to use such latest compliers like gcc 4.1.2-25, Microsoft Visual C++ 2005 SP1 and later versions.

Box Item

We should also use static and dynamic analysis tools along with manual code reviews to detect the commonly occurring vulnerabilities. However, these tools have considerable false positives and false negatives. Manual code review by experts should also become a part of the SDLC (Software Development Lifecycle). It is important to note that the results of manual code review are only as good as the person behind it. It is generally very difficult to detect complex logical vulnerabilities and hence having an understanding of the business, technology and hacking is essential to conduct such reviews.

Input and Output validation can be extremely effective in preventing several classes of vulnerabilities like XSS, Cross Site Request Forgery, Injection etc. However defining an algorithm for input validation may need complex logic to ensure that business functionality is not compromised for security. One can also use several anti-cross site scripting libraries (E.g. Microsoft Anti-cross site scripting library V1.5 etc) which provide one level of defense against XSS attacks.

It is also a good practice to canonicalize polymorphic expressions wherever applicable and avoid string concatenation for dynamic SQL statements. Using logging and tracing is very helpful for enhancing the security, debugging and monitoring.

It is critical to use cryptographic algorithms with care. It is generally safer to use well known and time tested cryptographic algorithms rather than inventing new ones. It is safer to use strong and known algorithms than non-standard and unsafe ones. Obfuscation is not the best strategy when it comes to algorithms. There are several known weaknesses in cryptographic algorithms and is better to avoid such algorithms (E.g. MD4, MD5, SHA1, DES, stream ciphers like RC4 etc). US Government has recommended FIPS 140-2 which defines a set of sound cryptographic algorithms.

Box Item

Phase 4: Testing and Verification Phase

Testing is one the most crucial phases for secure product development. Testing should be done at multiple levels like unit testing, integration testing etc. However there should great focus on conducting tests prior to launch of the product. Conducting in-depth penetration testing is not only important from a security standpoint but also builds trust among customers.

Penetration Testing

Penetration testing is becoming increasingly popular for testing the security of an organization’s IT infrastructure or critical applications from the perspective of a hacker. Application level Penetration Testing has especially become critical in today’s context. Penetration testing has also been mandated as a compulsory activity as a part of various compliances and certifications. Some of the major reasons why Penetration Testing has become popular are as follows:

• Determine if the current security systems are actually working in real life scenario.

• Determine if there are gaps between the design and the implementation.

• Prioritization of the true risk for quicker remediation.

What are the benefits?

• Determines if the security systems/features implemented are actually delivering the expected results.

• Provides a comprehensive proof of existence of vulnerabilities.

• Helps in better prioritization of vulnerabilities to be fixed.

• Helps in achieving several compliances for which Penetration Testing is mandatory.

What are the types of Penetration Testing and its techniques?

Black Box Testing: Black box testing is the approach where none of the internal details of the product are revealed. The tests are conducted from the perspective of an attacker with zero knowledge. There are several techniques used to conduct such tests like Fuzzing, Reverse Engineering, Exploitation etc.

White Box or Code Review: White box Penetration Testing or Code Review is the test where complete details of the product including the code and design documents are made available to the testing team. The team conducts tests using a combination of approaches using automated tools as well as manual analysis to find the different vulnerabilities.

Fuzzing: Fuzzing is a technique of creating intentionally malformed/specially crafted inputs to the system and check out how the system responds. Fuzzing or Fuzz testing is very effective in discovering Zero Day vulnerabilities and is widely used by vulnerability researchers. If the system gets crashed due to a particular crafted input, then the researcher further analyzes the data and tries to develop proof of concept exploit which can demonstrate how the system can be compromised.

Exploitation: Exploitation is the technique of developing codes which can demonstrate how a particular vulnerability can be leveraged to compromise a system. Researchers use several kinds of vulnerabilities like Buffer overflow, Format String etc to write exploits

Is Code review better than Black Box Testing?

It is unfair to say that any one of them is better than the other. Black Box Penetration helps one to find the low hanging fruits. These are the vulnerabilities which a hacker would potentially find in case he is trying to break into your system. White box testing/code review can potentially find more vulnerabilities than the black box approach. However the reality depends on how well such test has been conducted.

When should you conduct Black Box Testing?

Black Box Testing helps in finding vulnerabilities which a hacker would be able to find without having any knowledge of the system. These vulnerabilities are the easiest to find and hence should be the ones you need to focus on very first.

Black Box Penetration Testing should also be conducted periodically and at frequent intervals since every day new attack techniques are discovered. It is technically and business wise infeasible to conduct code reviews every month.

When should you conduct Code Review?

It is a good idea to conduct a Code Review once the system is completely developed and prior to its launch. Code review may be required for certain compliances too.

Complete Code review is much more time consuming compared to Black Box Testing and hence cannot be conducted frequently. Hence it is important to do a good job rather than an half hearted attempt for sake of conducting one. In such case the results may miss out several vulnerabilities which a hacker would potentially be able to detect with zero knowledge. In case of limited resources/budget, limited time and higher frequency Black Box is preferred over white box.

What are the common gaps in current day Penetration Testing?

• Penetration Testing results are only as good as the person doing it.

• No industry standardization of quality.

• Humanly impossible to determine all possible attack paths.

• Difficult to differentiate between good effort and a poor one.

• Impossible to find all logical vulnerabilities in an application.

• All Security consultants are not necessarily good Penetration Testers.

• Penetration Testing experts are extremely rare.

When to outsource and when not to outsource Penetration Testing?

It is very important to take a decision on whether you should outsource penetration testing or try to build in-house expertise. Both have their pros and cons and are suitable for certain situations.

In house Security team

Advantages:

• All information stays in house.

• Direct control on quality.

• Can be cost effective only if the volume of work is significantly huge.

Disadvantages:

• Very high investment in terms of tools and manpower.

• Very difficult to attract and retain talent.

• May not be aligned with business focus.

• Difficult and costly to maintain in-house research.

When to do Penetration Testing in-house?

• If you cannot allow an external consultant within your network (e.g. defense).

• If you have significantly large volume of testing requirement which are continuous in nature and hence justifies your high investment (Even in such cases 3rd party testing is a good option for very critical systems to gain neutral view)

Outsourcing Penetration Testing

Advantages:

• No investment on tools and people.

• Cost Effective.

• Specialized skill availability.

• Getting a 3rd Party perspective.

• Mandatory for compliance requirements.

Disadvantages:

• Difficult to find quality to Penetration Testing Organizations.

• Non standardization of quality and dependence on the individual conducting the test.

When to outsource?

• If your application/network is critical for business.

• If you want to focus on your core business.

• If you have compliance requirements.

When to conduct penetration testing?

• If you have a critical system for which you cannot afford a security breach or downtime.

• If you are launching an application/product, it is a good idea to conduct a Penetration Test before the launch or delivery to a customer.

• If your product stores critical data of customers or employees/conducts online transactions.

• If your customers are worried about your security and need third party assurance.

• Better security could mean more trust and hence more business from your customers.

• If you want to convince your management that you have a robust security or want to justify higher security investments.

When not to conduct Pen Test?

• If you do not find the right organization. The penetration testing result is as good as the people and technology behind it. Do not buy simple VA for Penetration Test.

How to select a Penetration Testing Provider?

A good penetration testing service provider can truly add real value to your entire testing initiative. There are scores of testing services available but you need to be cautious in selecting your penetration testing vendor. These are some of the rules which you may apply while selecting your next penetration testing vendor:

Focus on the vendor’s real knowledge and not just on certifications: By focusing too much on certifications, you would probably eliminate a lot of top-notch pen testers. Certifications and knowledge are not always synonymous. There are both good and bad “certified” professionals/vendors. It is important to look for knowledge and not just certifications.

Evaluate the technology competency of the vendor: Good indicators of technology competency could be:

• Does the vendor have proprietary tools and technology?

• Is the vendor known and respected in security research community?

• Has the vendor published original technology research in the Penetration Testing or Vulnerability Research domain?

• Is the vendor involved in vulnerability disclosures in known application

Look out for penetration testers (Specialists) and not for security consultants (Generalists): Penetration Testing is an art and needs real specialization. The most polished consultants may not essentially be the best with the keyboard. Look for the “real” Penetration Testers.

Pay for quality: Cheap testers are widely available and so are poor results that come along with it. Good testers are in demand and can command a good salary. The basic economics means the company will have to charge you the going rate.

Focus on methodology as well as technology: Good penetrating testing vendors focus heavily on methodology that ensures comprehensiveness and discovery of all possible attack vectors. It is also critical to check the tools and technologies being used to conduct such tests.

Reference Checks: Additionally word-of-mouth references are extremely valuable. You may talk with colleagues at other companies and find out what they liked and didn’t about the vendor.

Phase 5: Maintenance phase

No matter what you do, vulnerabilities will stay and would get discovered with time either by your team, customers or security researchers worldwide. Hence it is critical to create effective response mechanisms to collect such information and react to it as soon as possible. Several reputed companies encourage “responsible vulnerability disclosure” and has created a process to respond to them and release the patches effectively.

Improving the security of the product needs a comprehensive approach throughout the software development lifecycle. Standalone effort of code review or secure coding guidelines is not enough. Building a secure product is not just building a process but also the right mindset among all the stake holders. Only with a comprehensive effort throughout the entire SDLC, it is possible to reduce and contain the risks in an effective way.

Reference: Safecode.org, Microsoft.com, sse-cmm.org

—By: Bikash Barai, CEO, Co-Founder, iViZ — On Demand Penetration Testing.