As the number of devices, apps, users and customers grow around the world, the need for application security becomes an absolute necessity. It’s well known that today, software has evolved from being part of your business, to becoming a way to run your business and increasingly, it will be your business.
Floyd Fernandes, Vice President and Chief Information Security Officer, explores the important issues surrounding this space – dealing with emerging threats, developing programmes and making sure the human side of application security is not forgotten.
The Five Key Pillars
Within the software life cycle, there are five major pillars – static analysis, dynamic analysis, open source, threat modelling and education. Within those pillars, you need to look at where there is innovation coming out of startup or develop a changing mindset on addressing the kinds of vulnerabilities coming from software development.
Historically, security has generally been used as something akin to a penetration test, implemented at the end of a product release. But the reality is, that’s too late. There’s a concept called ‘shift left’, which is the idea that if you ‘shift left’ to earlier in the life cycle, when a feature is still being developed, and you test during that phase, you’ll have a better understanding and a better view of your ability to remediate issues, which will then be reflected in the cost of remediating a vulnerability.
Scheduling Security Fixes Across An Organisation
When it comes to remediating issues, or better yet, preventing them, the key is really about relationship building.
If you’ve built a relationship with the business unit, part of that is the notion of having somebody within that business unit be accountable as a security advocate, i.e. an individual who is held accountable in helping facilitate the application security pipeline.
Ultimately, the developer and the engineer within that business unit knows their product best. If they’re the key person, the security team takes on more of an advisory role. Propagating that process across the organisation means that the application security strategy is embedded in each product and is owned by the business unit.
Vulnerabilities & Technical Debt
There are many challenges around scheduling security fixes but the main one is centered around the sheer volume of vulnerabilities that are discovered. The signal to noise ratio is significant, which means that when you’re doing an assessment, you should assess whether the vulnerability is a false positive, within your code or whether it’s within the vast number of open-source libraries that a product uses. Generally, around 70% of code developed in software is open-source.
When you’re looking at these large volumes and trying to make an assessment, getting to the determined point of actual risk takes a long time. But because a lot of applications have already been released, trying to figure out how you also address technical debt becomes a major issue.
Technical debt is a set of vulnerabilities that are already within the application that have been procured over the years but were never addressed because either 1) there was never an assessment done against the application, or 2) the vulnerability was only recently discovered.
But once you get to a point of discovering the vulnerabilities, you should put together a remediation cycle on a regular cadence, including getting the business units to figure out how much they can tackle from a technical debt perspective as well as new code that’s being developed. A tactical approach to this is to align it with known exploits, which raises the inherent risk for remediation.
The Biggest Security Threats
The biggest threat is the fact that a lot of organisation’s still don’t have an application security programme. Security teams are still focused on what was information security, or compliance, up until now. Security used to mean looking at your perimeter, which was a defined environment inside a data centre. That shifts when you go to the cloud because you don’t have a garden wall anymore.
Organisation’s need to understand that even when you are trying to protect your perimeter, that firewall they’re using runs a piece of software, and that software may have a vulnerability which could be the inflection point that is used to gain entry.
Regardless of your environment, there’s always software running it and that’s where the vulnerabilities are being discovered. Whether it’s through the security services that are trying to protect it or through your actual web application, they all could lead to a way in.
Addressing the Threats
The number one thing that organisations should do to address these vulnerabilities is to look at getting an inventory of the application they’re developing and to start a culture around education. Rather than only using tools, it’s important to educate your development community on best practices and on how they write secure software.
From an application security programme perspective, education and awareness are first steps. The principal of ‘secure by design’ should be the focus of this programme.
When it comes to the cloud, it has removed the barriers that were in place before, increasing the pace and making it difficult to maintain visibility over the number of applications being developed.
Gaining visibility and keeping up with the pace of technological change in order to prevent issues are tough problems and ones which everyone is still looking at. Visibility into your environment is probably the first step in understanding your applications and getting a grasp of what you should do from an application security perspective to make sure you’re protecting your applications.
IoT and the Future
From cloud onwards, there is going to be a huge shift over the coming years. Application security will continue to grow year-on-year because of the Internet of Things (IoT). IoT is driven more by hardware devices, but every piece of hardware runs a piece of software. So you’re talking about hundreds of millions, even billions, of IoT devices and each one of those will be running a piece of software – that automatically makes application security a bigger focus than it currently is.
We saw late last year that certain home-cameras people have in their houses were vulnerable. Fundamentally, the issue was in the application that ran that camera, as it had a hard-coded password. That’s something you would detect through an application security programme, as discovery of information would be detected through its reporting.
This comes back again to education and awareness. A lot of these manufacturers, because they’re more in the industrial space or more in the infrastructure space, don’t have security teams so they’re not aware of the kind of security measures they should be implementing as part of their product release.
With IoT, because these are often new organisations, they’re not aware of the kind of implications their hardware or software is having on the world. That’s why education and awareness is important, regardless of application security, because it’s about fundamentally understanding the responsibility of designing secure software.
Security Meets Humans
Because IoT is not in a regulated industry, in the same way finance and healthcare are, there are no policies or regulations driving a certain level of safety. Take the car industry, for example, the reason we have seat belts and crash tests is because there are regulations on the minimum standards before you can release a car to market. Conversely, there isn’t an equivalent for the IoT industry at this point.
It gets more alarming when we start talking about IoT devices that are health-related, as now you’re dealing with a human element. What happens if someone compromises the IoT device that controls your heart monitor or glucose monitor? Now you’re affecting a human life.
To give another example, our cars currently use software to drive all the chips in it. That again is another area where the human element is affected.
There’s no doubt there needs to be a focus on application security when it comes to applications that are running our radios, our GPS, our brakes, or our engine because ultimately, it is a piece of software that controls the car.
Without application security, we are now raising the risk to the human population due to the potential vulnerabilities that may exist within the software that controls a car.
Simplifying the Focus
A recent InfoSec article reported that 90% of CISOs are still concerned about application security, mostly because they have not yet implemented an application security programme.
The focus has always been on the kind of attacks known as advanced persistent threats or ransomware. The focus tends to be on what’s newsworthy, rather than on understanding the kind of foundational programmes you should run that are applicable to your business risk.
Instead, the focus should be business-driven: what is your organisation’s strategy, what’s your tactical approach and what’s your operational approach to security? Once you’ve identified these, you need to look at launching an application security programme and following three key focal points:
Identify the steps you would take to build an application security programme
Building a security culture within your engineering department
Floyd Fernandes is a Winter Circle member and Vice President & Chief Information Security Officer at CBS Interactive.