This is part I of the Application Security story. Follow this link to part II in case you would like to directly access the poster.
What is the problem?
Many attacks happen on the application layer, where the usual network or infrastructure security solutions are less or not effective. Unfortunately, the majority of cyber security effort does not happen in application development.
Please note, that the human factor in terms of application user is also very important, as many such attacks are precipitated by social engineering attacks, e.g. with more or less well crafted phishing mails.
However, the following does not address the application user as we focus here on the application security development process and not on user risk. User risk and user psychology will always be very important for designing secure solutions as preventing social engineering attacks also requires to understand the user with all thinkable and unthinkable usage scenarios.
Following factors are at work which prevent a better focus on Application Security during development.
Factor 1: Mindset issue of “Security as Afterthought”
An important factor is the classical “Security as Afterthought” mindset in IT that haunts also Application Security. It certainly is a mindset which is deeply ingrained in the IT community and IT business.
In the best case, additional security can still be bolted on somehow after the release. In the worst case, it would not be possible to add such a patch because it’s too late and too costly to make the necessary changes.
Maybe it should rather be called “approach” than just “mindset” because it goes deeper than the attitude of a couple of IT stakeholders having some personal preferences. If it were only a mindset issue then it should be possible to change things radically and with ease if it turns out to be necessary.
Factor 2: Financial issue of “Security as Afterthought”
Up to now it often makes economic sense to run the risk and limit IT Security investment to what is perceived as inevitable at the very moment. Look at the figure below showing the cost curve of two different IT Security paradigms (reactive vs. proactive approach).
Under-investment in IT Security can become costly in the long run, especially when incidents back fire pressing urges require to add more and more security point solutions. However, under-investment can make economical sense on the first half of the cost curve (inversion part) if the preference is leaning towards the short run. Short term business preferences and a reactive approach towards IT Security have a lot in common.
The point is that it takes time and effort to switch to a more sustainable proactive approach with “Security by Design” or “Privacy by Design”. The long term goal should be falling marginal IT Security costs in the future, which means efficiency and effectiveness of security investments. However, this requires to prepare the ground ahead of time and invest with long term focus in order to profit from falling marginal cost in the future. Yes, this is about TCO (Total Cost of Ownership).
This curve is an simplification, but I am confident that this shift will happen once the point is reached when accumulated cost from Security investments and the fallouts from incidents start to grow out of proportion. Top management will then start to ask serious questions about return on IT Security investment and TCO of security solutions.
Factor 3: Complexity issue of Application Security
Application Security can be rather difficult and requires knowledge and experience to implement properly. Misunderstandings and wrong assumptions can have huge consequences. Security know how certainly should get more widely spread also in application development. However, do really all developers need to become security professionals?
The usual complexity in IT also applies to Application Security, notably dependencies to specific implementations, use cases, currently used technologies, libraries, frameworks and IT environments. Creating and maintaining consistency of security implementations across different projects, products and technologies within the same enterprise can be a huge challenge. One weak link or one mistake can break the whole. And there are many of such components which all require that everything is correct. Not yet talking about vulnerabilities.
This is also important from the perspective of IT operations and IT infrastructure. The tendency is to choose infrastructure security solutions with the aim not to interfere with the working of applications. Going for low hanging fruits might be a good thing from the infrastructure perspective, however, many such solutions are also rather reactive in nature and transparent to the application as result.
Factor 4: Separation of concerns between Development (Dev) and Operations (Ops)
This tendency is amplified with the classical separation between application development and IT operations. The good thing is that those who are responsible for IT infrastructure and its operations have a budget in which cyber security needs can be addressed. However, these stakeholders will choose solutions from their infrastructure perspective and not from Application Security perspective. On the side of Application Security, budgeting is far more difficult as it happens within individual development projects. This is so, because Application Security is perceived as project risk issue and not as security contribution for protecting also the rest of the enterprise.
Furthermore, an application developer would rather not use (and experiment) with infrastructure security features and IT Ops people try not to get involved and exposed to application complexities. IT operations and IT application development are completely different worlds and current IT governance/management frameworks support this separation of concerns. There are many valid reasons for this separation, however, some topics like IT Security often require a more holistic approach across such silo borders.
The recent DevOps movement is successful in overcoming this gap, reducing development and maintenance cost and speeding up time to market (TTM) substantially due to Continuous Delivery practices. It’s beneficial for the firm if Dev team and Ops team work more closely together and deliver more rapidly. However, it adds also some risk if it happens without an IT Security mindset, appropriate architecture and tooling. DevOps clearly needs to have some “Sec” between the “Dev” and the “Ops” in order to get also into something new called “Continuous Hardening”. You get the picture.
The DevOps style of Continuous Delivery is also popular when using the cloud. On the flip side, it also eliminates much of internal infrastructure, many operation teams and a lot of engineering experience. However, infrastructure and operations still matter. Some part of IT Ops now simply belong to another legal entity. The good thing is that a large cloud service provider is able to provide an even more secure infrastructure and also more solid security facilities and processes.
Patching and versioning might be better in the cloud than doing it oneself, especially for small and medium enterprises who would never have reached the engineering critical mass of handling security appropriately. However, the issue did not go away, which is, does your application actually use what the infrastructure or cloud provider is offering in terms of security services? In a coherent and secure way? A cloud provider might offer quite advanced services as standard but might not really care about your application as an application owner would.
Shift towards a more preventive and proactive approach required
A more preventive and proactive security approach would make sense in application development because it’s the application which exposes its data through their usage of APIs and interfaces to the external world of cyber risks. Ideally start the security process with “Security by Design” at the very beginning of a development project by thinking about threat scenarios and security requirements.
A security mindset and adequate tools and processes for continuous security hardening is required. During development, testing and operations. “DevSecOps” as approach might be helpful here, however, such a preventive approach is still rare in IT.
Shifting the focus towards Application Security is the logical next step (and a necessity) in cyber security – but it will require a substantial shift of mindset and management attention.
Application Security needs a good story in order to make this happen. Some buzzwords as “Shift Left”, “Security by Design” and “Continuous Hardening” are quite useful in order to promote this change.
Compare this with “Safety by Design” in the automotive industry
Compare the current security mindset in IT with the safety mindset in the automotive industry. It would be like delivering new vehicles without safety features and leaving it to the customer how to deal with missing safety items, e.g. by adding them (safety steering wheel, bumpers, safety glass, safety belts or anti-lock braking systems) after the purchase. Some safety measures as crumple zones or airbags are difficult to add afterwards as they require substantial changes on the car structure or interior design – which simply would be too expensive.
Fortunately, we don’t need to care much about the safety basics when ordering a car because the automotive industry went through decades of learning curves regarding active and passive vehicle safety. Unsafe vehicles are unacceptable nowadays. A producer would not get away with unsafe vehicles and for that, it would not be economical to design them without applying a “Safety by Design” approach in the first place.
Safety and Security: A quality issue after all
It’s somehow ironic that the automotive industry with its long history of “Safety by Design” is now unconsciously embracing the conflicting paradigm of “Security as an Afterthought” from the IT industry, especially with the advent of the interconnected car.
This is not supposed to be an article about the dangers of IoT and IT Security of cars, however as a side note here, it’s clear that the product safety paradigm of the car industry and the security paradigm of the IT industry are not compatible right now. A reconciliation effort on both sides might make sense.
The automotive industry needs to consider Continuous Hardening as update service far beyond vehicle end-of-production date as more and more cyber risk are introduced with interconnected functionality. The IT industry on the other hand should shift more towards “Security by Design” in order to improve the quality of typical IT products when they are shipped. Preventing future quality and safety issues of costly IoT assets is impossible without addressing IT Security during the whole product life-cycle and even for years ahead. Obviously, a tremendous economic challenge.
Reactive vs. Proactive Application Security
The current cyber security boom is a reaction to the constantly increasing number of security incidents. Clearly, there is a need for more secure IT products. The same can be said for Application Security. However, many of these activities are still reactive in their heart, and probably just a gradually better version of the “Security as Afterthought” approach. After all, you just need to buy some advanced security solutions, and to find and patch some security bugs.
Although this approach makes sense, there are limits which cannot be overcome with more infrastructure or more patching. A more proactive and preventive security approach would see this rather as issue of questionable product quality to begin with. Quality typically comes with additional cost first but it should be a benefit in the long run.
This seems to be difficult to change as most of the IT industry is supporting a reactive approach. However, the real question here is if the market will honor the change to a more proactive approach. The advantage of software is to deliver quickly and to remain flexible. As long as the cost-benefits are acceptable, it makes sense not to burden product development with things that can be patched afterwards. However, will this – can this continue forever? It’s a question which depends on the tolerance and willingness of all those who consume such products.
What could be game changers? The CEO getting tired of too many security incidents? The CFO complaining about the ever increasing cost of security and compliance measures? The consumer who looses faith in using vulnerable products? What if liability laws for software products would be introduced?
Making the reactive vs. proactive cost curves visible might hopefully spark a discussion about effectiveness and efficiency of IT Security measures. If cyber security is supposed to be more than just a momentous boom, then we might have to re-balance the effort regarding Infrastructure Security vs. Application Security in order to get a better and more sustainable cost/benefit balance from security investments. It surely will happen – as it happened with safety in the automotive industry – the only question is when.
Good story to promote Application Security
Nevertheless, it’s not that simple. Re-balancing this effort means more Application Security which could need a good story to start with. Most people are not aware about the meager state of Application Security and how difficult it is to apply a proactive and preventive approach – even if security best practice is known and understood by all stakeholders involved. Look at the OWASP 10 top vulnerabilities today and a decade ago and wonder why large portion of the IT industry is still suffering from the same old issues.
|
The “Shift Left” poster (on the right) is an attempt to compose such a story in order to promote Application Security. The idea is to visualize the relationship between application development and IT Security with the help of three useful concepts; one works on management layer for getting attention and support of senior management (“Shift Left”) and the other two (“Security by Design” and “Continuous Hardening”) for the IT people on the ground in the trenches (developers, tester, project manager, IT operations).
Follow this link to part II of this blog or click on the poster on the right. |
 |
Author: Roberto Di Paolo
Published 2017/08/31, updated 2018/7/25, rearranged 2021/8/31, © ACROSEC Inc., All Rights Reserved