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?
Most attacks happen on the application layer where network or infrastructure security solutions are less or not effective. However, the majority of cyber security effort does not happen in application development.
There are several factors at work which prevent a better focus on Application Security.
Factor: “Security as afterthought”
An important factor is the classical “Security as afterthought” mindset in IT that hunts also Application Security. Maybe it should rather be called “approach” than just “mindset” because it goes deeper than a couple of IT stakeholders having some personal preferences. If it were only a mindset issue then it would be possible to change things radically and with ease if it turns out to be necessary. However, it often makes also economic sense to simply run the risks and just cover quickly what is perceived as inevitable at the moment. The problem is that this thinking is deeply ingrained in IT and the IT business.
Factor: Application Security considered as too complex
IT Security risks get more attention now because of some spectacular cyber security incidents in the past few years. However, the old thinking is still alive and the mood still is better not to tamper with the Application Security layer when it can be avoided (factor 2) because Application Security can be rather complex and become expensive.
This is especially important from the perspective of IT operations and IT infrastructure as the tendency is to choose cyber security solutions with the aim not to interfere with the working of applications. Going for low hanging fruits might be a good thing from this perspective, however, many cyber solutions are also rather reactive in nature and transparent to the application as result.
Factor: Separation between Dev and Infra Ops
This tendency is amplified with the classical separation between application development and IT infrastructure operations (factor 3). 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 good reasons for this, however, the recent DevOps movement tries to overcome this gap in order to reduce development and maintenance cost and speed up time to market (TTM). This is beneficial for both parties but adding even more risk if it happens without IT Security mindset, appropriate architecture and tooling.
A more preventive and pro-active security approach would make sense in application development because it is the application which exposes internal APIs and interfaces to the external world of cyber risks. Ideally starting the security process with “Security by Design” at the very beginning of a development project by thinking about threat scenarios and security requirements. Afterwards, “DevSecOps” provides the security mindset and adequate tools and processes for continuous security hardening during development, testing and operations. 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 “DevSecOps” are quite useful in order to promote this change towards proactive security and continuous hardening on the application layer.
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 it 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 would be difficult to realize because they require some substantial changes e.g. on the car structure or interior design – which would not happen often because 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. It would be unacceptable nowadays that a producer gets away with unsafe products and for that, it would not be economical for them to design vehicles without applying the “Safety by Design” approach.
Side note on Safety and Security: A quality issue after all
It is somehow ironic that the automotive industry with a long history of “Safety by Design” is now unconsciously embracing a conflicting paradigm from the IT industry with the advent of the interconnected car. However, this is not an article about the dangers of IoT and vehicle IT Security, but it is clear that conflicting paradigms regarding product safety and IT Security are at work, which will need to be reconciled on both sides in order to make sense in the long run.
The automotive industry needs to consider continuous hardening as update services far beyond vehicle end-of-production date as more and more cyber risk are introduced with interconnected functionality. IT industry on the other hand should shift 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 beyond. Obviously, a tremendous economic challenge for both producer and consumer.
Different approaches, different cost curves
The current cyber security boom will need to evolve towards a more proactive and preventive security approach as this is also an issue of product quality. However, quality comes with additional cost first but will be more beneficial in the long run.
Such a perspective might hopefully spark a discussion about effectiveness and efficiency of certain security measures. If cyber security is supposed to be more than just a momentous boom, then we have to rebalance the effort regarding Infrastructure Security vs. Application Security in order to get a better and more sustainable cost/benefit balance from our security investments. It surely will happen – as it happened in the automotive industry – the only question is when.
Nevertheless, it is not that simple. Rebalancing the effort involves 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.
The poster on the right side is an attempt of developing such a story in order to promote Application Security. The idea is to condense the story so that it can be expressed with the help of three buzzwords; one is especially useful for getting attention of senior management (“Shift Left”) and the other two (“Security by Design” and “DevSecOps”) for the IT people on the ground in the trenches (developers, tester, project manager, IT operations).
Follow this link to part II of this page or click on the poster on the right.
Author: Roberto Di Paolo
Version 1.2 2017/08/31, last update 2017/9/27, © ACROSEC Inc., All Rights Reserved