Security engineering: Glide path for software products

Introduction

Product managers and R&D leaders today are inundated with mountains of best-practices and advice for adopting security compliances for their software products. The market today needs software products and data, which is secured not only to cater to business requirements but also for regulatory compliance.

Products are evolving at breakneck speed, getting more complex day-by-day, which gets coupled with requirements of cyber & information security, privacy and fraud prevention. Product managers juggle the trinity of time, scope and cost.

This ruckus around security has been a fertile ground for a mushrooming of boutique consulting shops that promise to solve the puzzle for you. Is it productive to engage them? Are product managers able to identify the end-state of security adoption they want to achieve and the path to get there?

This article cuts through the clutter and helps product managers map their products to the possible end-state they want to reach on the security engineering adoption.

Security engineering – maturity journey

Let’s begin with mapping out the security engineering journey– the bedrock of achieving security compliance for the products.

Security engineering encompasses policies, processes, tools, and standards needed to design, build, and test software systems compliant with the security requirements. These requirements could be of the product as well as regulatory compliances. Its implementation in SDLC spans a wide spectrum from basic gating mechanisms to new-age intelligent solutions.

SEE ALSO: Diversity talk: “We need to ditch the idea that women don’t love their careers as much as men do”

Security engineering has evolved and matured over the years on the collective knowledge of the software products industry. All products traverse the security engineering journey defined below. Different products on this journey can have a different start point and can choose an end state that fits their needs and budgets.

The basic approach is most relevant in the context of legacy enterprise applications that relied on fundamental constructs of:

• Authentication
• Authorization
• Access Control

This was usually driven by the basic product requirements and evolved into standardized frameworks, slowly evolving into capabilities like Single Sign On (SSO) for improving user experience. The identity of the user was the key paradigm, supported by controlled access to network interfaces.

The reactive approach focuses on ensuring the product complies with the customer’s adopted security framework. This requires the implementation of pre-release checkpoints like VAPT (Vulnerability Assessment and Penetration Testing), system hardening and firewalls, incident management, and reporting. A security analyst in this approach can be a consultant or part of a product verification team, whose role kicks along with the QA team.

The proactive approach kicks in during system design and focuses on building security into the design and implementation of the system. This includes defining security requirements covering risk analysis and threat analysis to implementation through secure coding and code analysis. Its end goal is to prevent a breach in all system flows. The proactive approach is in addition to reactive, and not a replacement of it.

The predictive approach is knitted into the DNA of the product and aims at predicting hitherto unknown security events. The approach leverages the application of machine learning / deep learning networks to pre-empt and/or limit the damage caused by threats like malware, network intrusion and insider attacks. Compared to rule-based solutions, this builds the ability to forecast and mitigate day-zero attacks. Under this security as the primary need and the design is not only to meet the discovered vulnerabilities but also those which can be discovered later in the field. This is the highest maturity level with intelligence is built-in respond gracefully and limit impact if subjected to a new threat or attack. It bases its design on observing the system, environment, and user behaviours and leveraging the past knowledgebase to prevent or report.

Identifying security engineering end state for my product

A product manager needs to answer the following questions: – What is the right security engineering end state for me? What is the minimum? When should I stop?

The current state of security compliances will define the security engineering journey start point, but the big question is where to stop? While most security consultants will advocate adopting a proactive model, but the big question facing product managers is – are there more choices? Is that the only right way? Does it fit the cost, schedule, and skill level of my product and team?

The argument in favour of going proactive is grounded in the fact that finding and fixing a software problem in later stages is exponentially more expensive than during the design and requirements phase. On the face, this looks obvious, but on deeper analysis, it exposes that other options that could be more appropriate in various stages of product maturity are conveniently overlooked.

A good example is – one can probably retrofit seat belts, but not airbags in an old car! So having an air-bag is not a wrong recommendation, but is it the right advice for my car?

Product managers can use the following thumb-rule to have a starting point for their decision. The choice can then evolve as the cost-benefit is computed.

The product manager and R&D leader when calculating Return-on-Investment (RoI) of security engineering, can map the product maturity stage to the desired end-state of security engineering.

As a rule of thumb, the choice of end-state of security engineering implementation has an inverse relationship with the product maturity lifecycle. The higher the product maturity, the higher is the cost of adopting security engineering – hence the steep decline in RoI.

Investing in security compliance – How much is too much?

All product managers would have sat through presentations by boutique security consultant shops who open their pitches by examples of multi-million dollar losses by corporations due to cyber-attack or regulatory penalties. This scare of worse sets in a bias that will make any investment a worthwhile one. And that’s the time to…..take a pause!

While there are a plethora of checklists and recommendations available around planning the budget for security – what has worked for me the best is my approach. Start with t-shirt sizing based on the stage of the product.

Once a product manager has defined the t-shirt sizing, the regular defined templates and best practices take over. They now have to play within the boundaries of the identified budgets.

Dilemma of product managers – customer-specific tailoring

Enterprise software Independent-Software-Vendors (ISVs) have an additional dimension of adapting to the need for their enterprise or institutional customers. The ability of these enterprise customers to arm-twist ISVs in changing their products throws another challenge to product managers. How do you define a common minimum set and not let customer-specific adaptions make their products overly complex to maintain?

Offering managers/solution architects responsible for creating the offer and solution based on the software product and need to know – what they should expect from base (core) product versus what tailoring should be applied to security aspects while creating the offer. That is capabilities against Minimum Security Requirements (MSR) of the base product.

Typically, all enterprise or institutional customers would have adopted a security framework, which will form the backbone of compliances that they will look for – in an RFP or through another compliance check methodology. Let’s begin by understanding the security framework, this may be referred to with different terminologies at different organizations.

Product managers of ISVs will need to enable their products to build capabilities that make their products compliant and/or adaptable to the security frameworks of their customers. The fragmented frameworks in the market make it difficult to define requirements that will meet all customers’ needs.

While security frameworks vary in complexity, there is a significant commonality in terms of general security concepts. In most frameworks or compliance requirements product managers will find questions related to aspects like:

Product managers can lean on to the information from market opportunities, regulatory requirements, competitors, user needs, and past security incidents to define a Minimum Security Requirements (MSR), that should be part of MVP (minimum viable product). This can then be gradually marked as “best in the market” eventually to “market leader”.

Again, the end goal will be determined by the product maturity stage, and is not a one-size-fits-all recommendation. MSRs must include Secure Engineering practices, Security implementation, and Privacy compliances. This spans Hardware, Software, Network, Tools and People.

Security engineering adoption – it’s a cultural change

Security in product engineering is no longer an afterthought. The risks of ignoring it and the benefits of adopting it are significant. However, a positive Return on Investment (RoI) alone will not lead to its adoption; a strong culture around security needs to be promoted by leadership.

A security engineering champion – internal or consultant – drives this transformation.

SEE ALSO: Global developer report: 11 million devs actively use JavaScript

This transformation is no different from the adoption of any other process change in an organization and hence for its success, one needs to ensure support from all stakeholders – executive buy-in, product management, engineering leaders, architects, developers, QA, and implementation.

To sustain post-transformation, the security engineering champion hands off the baton to security engineering practice. They help product teams in identifying the end state and handhold them through the journey. They supplement cultural transformation that needs to be supported through extensive training, processes, toolsets labs, and subject matter experts. This also provides continuity in terms of keeping the organization abreast of the evolving scenario.

Conclusion

Security engineering adoption in enterprise products is a given expectation in the market today. Every organization needs a mature security framework and all ISV selling software products need to be compliant to that.

While in general proactive prevention is better than a reactive response – it is more economical, faster, and safer. The key is to strike a balance between product maturity, security engineering end-goals, and business constraints of skill, budget, and time.

Security consultants play an important role in the overall scheme of things, especially considering the high cost of tools and skills which is tough to amortize over a single product/year. At the same time, one should be cautious that one is not embracing one-size-fits-all solutions and end either overspending or overexposed to risks.

With security breaches, frauds, and cyber-attacks growing and RoI rising for hackers, product managers have to keep revisiting their security strategy on an ongoing basis.

The post Security engineering: Glide path for software products appeared first on JAXenter.