Proactive security engineering

Software product engineering today needs to build security into the application, security capabilities cannot be bolted on after the fact. The means to make this happen is to have an integrated security and software development lifecycle – Secure Software Development Life Cycle (Secure SDLC).

A Secure SDLC practitioner ensures that the development process is geared to producing secure software. The process doesn’t limit itself to security gating at various stages of development, which always has a risk of vulnerabilities leaking. It follows a preventive approach to not let vulnerabilities enter the software.

Threat from attackers is real as they are looking to exploit the slightest weak spot. Need for Security built into the software product from bottom-up is now an essential part of the development lifecycle as incidents of attacks by hackers and fraudsters are increasing every day – both in terms of frequency and impact.

This article presents an uncomplicated view of Secure SDLC for practitioners – Engineering leaders, Product Managers, and Process Leads.

SEE ALSO: Python tutorial: An introduction to the programming language

Software development lifecycle and security

As proactive security engineering gains ground instead of security compliance coming into the picture in late stages of product development.

Engineering teams follow various flavors of the Software Development Lifecycle (SDLC) that need to undergo a revamp. This figure presents a simplified view of SDLC.

For SDLC to embrace security at every stage each stage requires to be revisited from the perspective of security. Process Playbooks and/or Quality manuals of most product engineering organizations will have well define Software Development Lifecycle (SDLC) for ensuring the management and quality of the software products. This brings inconsistency of methodology and predictability of the process in terms of time frame and cost.

Security Development Lifecycle (SDL) supplements and enhances all phases of the Software Development Lifecycle (SDLC) for security considerations. This enables teams to build secure software adhering to security requirements and regulatory compliances in a cost-effective manner. This enhanced process is referred to as Secure SDLC.

Security as an NFR

Bringing security engineering in practice begins with identifying ‘Non-Functional Requirements’ (NFRs) related to security by product managers. As with all NFRs, these deal mainly with areas that are not functions or features of the product.

Some examples of security NFRs are:

• Users must change the initially assigned login password immediately after the first successful login
• Password restrictions – length, special characters, expiry, recycling policies
• An unsuccessful attempt by a user to access shall be recorded on an audit trail
• User-level access permissions can only be changed by the administrator
• Operation/session timeout – duration, actions, audit trails
• Encryption both for data in transit and at rest
• Credit card information must not be visible or stored in plain text

These should align to following principles – (Reference: Microsoft SDL – SD3)

• Secure by Design
• Secure by Default
• Secure in Deployment

Unpacking Secure SDLC

In Secure SDLC, security is an active activity across all SDLC stages. Relevant stakeholders – product owners, developers, security experts, testers, deployment, and operations participate starting early stages of software development.

Security considerations are rolled in at the initial planning stage. This helps uncover security vulnerabilities and detects early in the development lifecycle (left-shift), which mitigates business risks. This also is an opportunity to reduce remediation costs as early discovery results in significantly lower costs.

Security activities overlay spreads across all stages of. This figure summarises activities for each of the SDLC stages from the perspective of security.

Let’s see how the addition of security to all stages of SDLC modifies it:

Define Stage is where product owners should articulate the Security and Privacy objectives which should get modelled into business requirements. This is also the stage to identifies domain, region and solution-specific compliances that may be needed both from regulatory or security purposes. For instance products in Europe shall have to comply with GDPR, Health-related products shall have to comply with HIPAA. Further, a health-related product in Europe will need to comply with both – HIPAA and GDPR.

The design Stage needs to take care of risk assessment based on requirements from the Define stage. It includes identification of security areas for the product and security requirements – both functional and non-functional. The design must consider security and threats identified in threat modelling to ensure this gets considered in implementation. A security design inspection with full conformance should be the exit criteria from this stage.

Develop Stage translates the secure design into implementation. The implementation adheres to secure coding guidelines, leverages tools to ensure clean and secure code. This is not only for the code created but also for any 3rd party components used. A successful secure code review with all feedback closed along with passed penetration testing should be the exit criteria.

The deliver stage takes care of environmental factors like platform, network, physical access, and personnel. Secure operational tasks are defined to pre-empt any breaches along with clear Standard Operating Procedures (SoPs) in case of any breach. There needs to be a well-defined feedback mechanism back to the product management team to ensure all incident and leaked vulnerabilities are adequately addressed in future releases.

Security engineering left-shift

Often, product engineering teams practice security compliance as part of testing activities or deployment pre-requisites. These late discoveries impacting security meant:

• The high cost of remediation, late discovery of architectural constraints
• Schedule slippage and uncertainty
• High risk of leakage of security vulnerability into production

Thus it’s prudent to integrate security-related activities across the SDLC to help pre-empt vulnerabilities early in the product development lifecycle, effectively building security in every stage. Otherwise, final delivery pressures may lead to decisions favoring patches and workarounds leading to security vulnerabilities leaking into production.

Effectively, Secure SDLC helps uncover the security and risks early in the product development lifecycle, leave enough schedule at hand to address them and increase the probability of timely successful delivery.

To successfully achieve this all organization needs to get aligned to revised methodologies and hence a strong need to revise Quality or Process Manuals followed for product engineering.

Revisiting software process and Quality Manual

Quality Manual contains the specifications for the quality management system (QMS) of a product engineering organization. It is a guiding document for navigating the organization’s QMS. It states the goals and objectives for the QMS with responsibilities. It can include policies for all areas of the business that affect the development of high-quality products.

The quality manual should be updated to align with the additional requirements of secure SDLC. This is also an opportunity for process leads to align security activities to organization needs, drop the ones that are not applicable and merge some into the standard SDLC activities.

Once defined Quality Manual becomes the reference for process audits.

Secure SDLC – does the SDLC flavor matter?

Software development methodologies have evolved over the last few decades embracing the changing needs from to time. Dr. Winston W Royce in 1970 introduced one of the first structured methodology of software development as a sequence of seven steps, which is often referred to as the waterfall model. He also highlighted the limitations of a sequential process and the need for iterating.

Over the years, various flavors of SDLC have evolved like – Waterfall, V Model, Spiral, Iterative, Lean, Agile – each one of them has its own set of advantages as well as disadvantages over the others. Though the models vary, all methodologies have the common objective of providing a framework for development teams to deliver high-quality software cost-effectively.

As the blocks identified in SDLC constitute each of these flavors – Secure SDLC applies to each of these flavors.

SEE ALSO: Objective-C in 2020 is still kicking in small communities as Swift gains popularity

Security NFRs to technical requirements or user stories

Security NFRs need to get translated as Technical Requirements or User stories (depending on SDLC flavor followed) which can be tricky to draft as these are anchored in risk mitigation. One of the best practices is to include the security goal as rationale with each story so that developers build it from the end-user / production environment perspective.

Product managers must realize that lack of clear security NFRs and corresponding requirements/stories can lead to these requirements falling through cracks. A mistake that can cost dearly in later stages of product development.

Leveraging DevOps

SDL ensures security is not left to a late stage, this also means that some activities may require to be repeated/iterated through the lifecycle. Here Secure DevOps or SecDevOps can be a valuable enabler when integrating security and agility.

Security gets knitted into every stage of the DevOps pipeline and not just the exit stage. SecDevOps integrate various security testing tools as part of the pipeline like SAST, DAST, VAPT, Fuzz testing and more.

Secure SDLC benefits

Secure Software Development Lifecycle (Secure SDLC) is a key focus area for product engineering organizations. Adopting security as a part of the development process to reduce the risk of vulnerabilities and threats, leads to reduced security incidents and damages.

For engineering teams reduces the risk of schedule and cost overrun. It helps build:

• Software designed for security rather than adapted for security
• Lower cost for security compliance by building into early architecture and design
• Early Detection of security issues results in better quality code
• Effective resolution of security vulnerabilities

It’s the way to left-shift the security activities in the product development lifecycle and reducing the security risk in production at a much lower cost.

The post Proactive security engineering appeared first on JAXenter.