Where's the Sec in Mobile DevOps?
Mobile applications are becoming an indispensable platform for organisations but if left unchecked they can provide an easy attack surface for malicious actors. So what steps can businesses take to ensure they don’t hit the news headlines?
Rela8 hosted a roundtable that brought together a group of cloud architects, IT, software engineers, information security, intellectual property and process & innovation professionals to take a deeper look at:
- Considering a mobile app as a digital platform
- ‘Baking security’ into Mobile DevOps
- Why security should be a top priority at the initial app development phase
- The digital shifts in mobile app security during the last five years
Rela8 Group’s Technology Leaders Club roundtables are held under the Chatham House Rule. Names, organisations and some anecdotes have been withheld to protect privacy.
About Zimperium
Zimperium Inc is a global leader in mobile device and app security, offering real-time, on-device protection against both known and unknown threats. The company recognised that traditional endpoint security technologies were insufficient to solve the growing problem of mobile security. Mobile devices had unique characteristics, which meant a completely new approach, so the team reimagined protection.
The result was the award-winning patented z9 machine-learning based engine. z9 protects mobile devices from device, network, phishing and application attacks. z9 has detected 100% of zero-day mobile exploits in the wild without requiring an update or suffering from the delays and limitation of cloud-based detection – something no other mobile security provider can claim.
Development risks
With everything that has gone before, running the code for new applications has been inside the firewalls of an organisation, but mobile apps are different, they are running on end user devices. When building mobile apps, developers clicking together building bricks, often without realising what they are bringing with them. Once in a public app store, threat actors have all the time in the world to reverse engineer it, clone it, or build something bad into it. Apps are running in a hostile environment on devices that are never updated and on bad Wi-Fi networks.
Mobile platform development and security risks
When companies want to produce a mobile app quickly and they add in a security element, costs can escalate, and the timeframe can elongate. But if organisations do not follow at least the minimum-security requirements, they can find themselves in the position where manufacturing stops because of a breach on a small app, where the company tried to save a few thousand dollars. This can end up costing millions of dollars to fix.
From the view of DevOps, security should be created from the first approach. It should come right at the beginning of development, not as part of checking at the end. It is part of the development life cycle. There are always challenges when it comes to funding and the timeframe of development, but whatever the cost is, to fix security during the development phase will be a fraction of the cost of fixing it when businesses are ready for production.
Companies need to approach mobile app development from a people, process and technology viewpoint, making sure teams include a security expert. The expert should know how to integrate into CI/CD pipelines which remove manual errors and provide standardised feedback loops to developers. Security should be a ‘guide dog’, not a ‘guard dog’.
‘Baking’ security into mobile DevOps
If agile technology doesn’t have security built in, then problems are built in too. This is where ‘baking’ in security can make a difference. Of course, there is a cost to paying for security, but there is also the cost of a delay to market, of developers having to slow down features, and of a possible security breach post-launch.
Security isn’t just about writing codes but how they are attached. Codes have to be manipulated, then developers write a sequel of defending codes in the open process and use the CI/CD pipeline for analysis. Best practice would be mandating compliance automatically in systems and source code. If security rules and boundaries are defined, then developers can use automation in the pipeline.
The shift towards mobile app security
One of the biggest challenges culturally, is that organisations don’t understand mobile. They don’t understand what is different about mobile platforms, or mobile apps. So organisations have to be educated on what makes mobile different.
There are two definite areas of security risk in mobile technology – devices and apps. They are related but different. For example, if a company publishes a mobile app, it can’t protect the device the app is going to write to. In this instance, the only thing it can protect is the app itself.
One of the primary obstacles for driving security into mobile apps is the ability to do it without impacting the app itself - its speed, size or performance. If an app is locked down so that it is slow and clunky, it won’t work properly, so security teams have become enablers and not throw up roadblocks, allowing the app to work to its maximum performance.
For device security, an inhibitor to a successful rollout for protecting employees on company devices is privacy, because there is something about a mobile device that is personal, even when corporate. Some companies are taking the stance of not protecting the whole device but instead protecting access to applications on that device i.e. having a security requirement for the device before an application can be accessed.
How DevSecOps will benefit mobile apps in the future
Going forward, accountability should be moved into the product, having a product mindset and product setup for new apps. As part of this, security architecture should evolve in the first phase, not when the product goes through a penetration test. In this way, the security architect is part of the process.
Different automated processes should be employed throughout the development, such as code analysis, automatic penetration tests, checkmark by source – all these can be used as part of the pipeline. If it is all brought into the product, the product owner can run things, not just manage them then summon someone else to check. The security person is part of the product team, so they work together, solving problems and security has become part of the development process.
Build in security
Companies do not want to pay millions of dollars to fix a security breach on a mobile app. Although they want to get a mobile app to market as quickly as possible, security should be built into the development process at the beginning to avoid this scenario.
There is a cost for security, but businesses need to recognise that there is also a security cost if an app’s launch is delayed. There is a cost if the speed of development is compromised, and of course there is a much greater cost to fix a security problem after launch.
There are obstacles to building security into mobiles, both devices and apps. Security can affect the performance of an app, making it slow and cumbersome. Additionally, companies cannot protect any device that their app is uploaded to, so many are now taking the approach that there has to be a certain standard of security on the device before their app can be accessed.
Security needs to be built in at the start. Employing a product mindset to new app development, with a product team including a security person, ensures security is part of the process and any problems along the way are solved by the product team and security in unison.