Software Security - How to get it right

In our world of ubiquitous technology, software is the most easy target for adversarial attacks. We have all witnessed the sharp growth of the next industrial revolution. A few articles read online are citing Industry 5.0 to be the next phase where collaboration between human and robot (cobot) disprove the theory that artificial intelligence purported to replace human workforce in some industries is no longer a threat. Apparently, we now need humans to support robots in areas such as supervision and validation of their work products. Some good news at least, whew! The dream of living-off Government support whilst bots do all the work don't appear to become a reality afterall. Oh well, the 9 - 5 hustle still continue. But all these technology have related software or applications to make them useful. However, statistics shows that these software are plagued by vulnerabilities making them easily attractive to adversarial compromise.

The Problem

Advances in hardware components such as smaller sensors, energy harvesting among others has made device production less costly in some cases. With a reasonable budget in hand, one can build a prototype device, solicit for funds, and in no time have an operational product line. The speed to deliver these products, perhaps to repay investors pushes many businesses to adopt "Agile" methodology. Not, that Agile is wrong for what it is, but it's real meaning and application is misunderstood by many and often mistaken to be as quickly adding new functionality or feature, and to put product on the shelf for consumption. And has resulted in security being an after thoughts or completely missed in development. Startups are building product without security or privacy considerations. Some don't even have security personnel within their businesses to advise them on what to do to make a secure product. Big businesses tend to get it right and are often seen hiring security experts to instill security in their way of life. Afterall, they have the required budget to do that, however, not so much can be said for startups or small to medium enterprises. There's an increased risk that our privacy and security would be abused as devices with connectivity grows into the top billions.

The Challenge

Security is about buying time - make it unappealing and time consuming such that the benefit of a breach to the adversary is outweighed by the cost, resource and time required to pursue their effort. I know this isn't an easy feat and perhaps you're thinking, it's easier said than done. Agreed. But we need to ask the following questions:

How much time have we spent on securing our product? - Adversary have all the time.
How much did we invest in security of our business and products? - Adversary may have adequate funds.
How much resource are in place to help secure our business and products? - Adversary have the resource.

The answers to the above three questions would either set you up on a journey to manage your security risk or completely ignore it. So you see, building security isn't hard afterall. Not really. We often struggle to get the necessary support from the business. By that, I mean budget to embark on a secure development lifecycle often is minute or not granted at all. Additionally, it's difficult to show value for why one needs the money, and can be attributed to the fact that mostly budget is sought to buy a new security tool. Instead, we could create a business case demonstrating the fact that our security processes and related technology enablers are either weak, outdated or not supportive of our current objectives. How do we do that?

The Solution

Well, I think we need a secure development lifecycle framework aimed at assessing the as-is to identify gaps. Further, secure development is intangible to account for. Perhaps, it can merge with security operations as an added function or time we created a secure development team! I would have called it security architecture but that discipline is losing its purpose and value with too many architects about who don't possess the necessary technical knowledge and experience to design secure solutions. A new framework is needed that encompasses existing secure software development lifecyle framework, expand it to include all aspects of a product - hardware, software, network. The initial step to adopting this framework requires assessment of ones internal maturity of secure development. The output of which will determine your capability maturity on a development journey. The key part is to use this as your business-case to inform your investors or leadership team about how weak your capabilities are to make your product secure. Highlight the gaps, and let them put their signature on it, as to their preferred option. But we need to support them and not just "do you want a secure product or not?". This requires some quantitative risk assessment in support of the qualitative output already obtained. The former will be for another post. But the outcome of such an excercise is to make the investors or leadership team take responsibility of all risk decision away from information technology and security functions!