Security Development Lifecycle

Secure Software Development Lifecycle (SDLC) is a must for each software development company striving to be competitive in the market. With a view to keeping pace and providing our customers with more reliable secure products, we have integrated the best security practices into our development process. In particular, Protelion SDLC (ISDL) process takes into account the recommendations of NIST (e.g. NIST SP 800-64, SP 800-100), the OWASP materials, and the requirements of ISO/IEC 27000 series.

ISDL is a comprehensive organization-wide process including the following:

AWARENESS AND TRAINING PROGRAM

The ISDL would be compromised without an effective Awareness and Training Program. We have developed a set of in-house training dedicated to overcome a lack of information security awareness, support, and enhance the professional competence of the personnel focusing on their responsibilities and duties within the ISDL process. The training is not limited by security practices applied during the process but also involves some practical skills sets necessary for the technical staff.

Requirements Gathering

The definition of product requirements boils down to a trade-off between the business need of a customer and the level of security required to protect his or her assets. This can only be achieved by gathering and thoroughly analyzing Market-based Requirements, applicable Laws and Regulations as well as Standards and Best Practices.

Market-based Requirements

Market-based requirements gathering implies identification of a customer’s problem to be resolved by a product or a service. As a result, at this step, it is important to clarify many things, for instance, the type of data to be protected, the necessary functionality of the product, any restrictions related to the operational environment, and so on.

Laws and Regulations

Earlier consideration of all applicable laws and regulations results in decreasing costs, risks of non-compliance, as well as product’s time to market (TTM) as a whole.

Standards and Best Practices

Despite the fact that laws and regulations do not usually require compliance with any Standards and Best Practices, the latter are still compulsory for each vendor wanting to be competitive.

Design

During this phase, we analyse the gathered requirements to understand how the product is going to fulfill them, as well as how to make this fulfillment more reliable and secure. Therefore, we examine Third-Party software if we are going to use it, perform Attack Surface Analysis and Threat Modeling.

Third-Party Security

In case of commercial third-party software, we oblige our partners to notify us about identified vulnerabilities as soon as possible in order to take necessary measures and prevent their exploitation. Additionally, we automatically monitor information about vulnerabilities discovered in open source software, which is incorporated or going to be incorporated into our products, to make necessary changes in a timely manner.

Attack Surface Analysis

The purpose of this Analysis is to identify what is available for and, consequently, can be used by an attacker, in order to minimize this as much as possible.

Threat Modeling

Threat modeling is one of the most critical steps for development of a product with security in mind. Therefore, taking into account the findings of the previous step, a threat model must be developed. Then, the model is used to determine the required level of security and to choose appropriate security controls to be implemented within the product in order to protect information properly.

Development

Secure coding is primarily focused on prevention of coding errors during the Development phase. This can be accomplished through:

• The implementation of a rigorous Secure Coding Standard, monitoring and control of its fulfillment by conducting Code Analysis, and
• The integration of up-to-date automated tools (static analyzers, compilers, version-control mechanisms, and others) into a software development environment.

Secure Coding Standard

We have developed an in-house Secure Coding Standard, implemented it into our product development process by addressing its requirements within our Awareness and Training Program. Then, we made the Standard mandatory for each member of the technical staff involved in the process.

Code Analysis

Secure code analysis conducted by security experts and peer code reviews are intended to eliminate errors at the earliest steps of development. They are quite effective for discovering logic mistakes regardless of whether or not such mistakes are deliberate.

Automated Tools

Automated development tools (e.g. compilers, version-control tools, code analyzers, etc.) and their appropriate configuring are necessary for software development. Moreover, they must be kept up-to-date to be effective and therefore, we strive to integrate the latest versions of such tools into our development environment.

Verification

The purpose of this phase is to verify that a product complies with the specification requirements and the required level of security. While integration, regression, and unit testing are helpful for functional evaluation, security testing, vulnerability scanning and penetration testing are a crucial part of security testing performed at the Verification Phase.

Security Testing

Security controls must be tested at this Phase in order to verify that they are developed properly and, actually, provide the required level of security.

Vulnerability Scanning

Automated vulnerability scanning performed periodically detects and eliminates vulnerabilities before a product is released. Additionally, it is recommended to fulfill fuzz testing at this step to check that a program responds correctly to both expected and unexpected input values with a view to identifying buffer overflows, input validation errors, as well as other security flaws.

Penetration Testing

Penetration testing performed by security experts is effective for discovering sophisticated vulnerabilities, and, as a result, fruitfully complements vulnerability scanning performed by automated tools.

Release and Support

Each of our products is only released if the Final Security Review conducting by the product development team and our security experts has successfully done. We have also prepared an Incident Response Plan in advance in order to respond to possible security issues. We provide our Customers with a Technical Support Service (link to the Policy) and all the necessary information about the expected changes in our products in due time.

Final Security Review / Certification

The Final Security Review focused primary on the evaluation of product readiness including issues related to its security, and, if required, certification of a product, as well as further making decision concerning whether or not to launch a product into the market take place at this step.

Incident Response Plan

No company wants to develop vulnerable software. However, errors, omissions, and other undesirable things do happen, as well as new vulnerabilities are discovered. Therefore, a ready Incident Response Plan is crucial for saving time and money.

Configuration and Change Management

Almost each out-of-the-box product requires to be properly configured to operate in production environment. Thereafter, the product must be monitored and updated when required (e.g. due to a release of a new version of the product, a need to correct uncovered coding errors or vulnerabilities) in order to continue ensuring the required level of security.

Disposal

When it is time to disposal of a product (due to its obsolescence, a need to update, or for any other reasons), protected information must be still kept securely. In order to address this properly, a disposal process should be planned and thought over beforehand, paying attention to security measures, which should be applied to preserve valuable information, sanitize media, as well as, overall, dispose hardware and software.

Information Preservation

Preservation of the valuable information implies not only ensuring availability of such information (e.g. when required by law), but also ensuring its protection during and, if applicable, after product disposal.

Media Sanitization

A special emphasis must be put on media sanitization (by overwriting, degaussing, or destroying) needed to prevent disclosure of sensitive information, which can be performed by using approved techniques and equipment chosen in accordance with the required level of security.

Hardware and Software Disposal

While physical hardware disposal is almost always required only if sensitive information cannot be sanitized by other means, removing of outdated software is usually strictly recommended because otherwise this software can result in any new risks.