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.
It is the classical “Security as Afterthought” approach which is so common in IT that hampers Application Security. Furthermore when it comes to cyber security, most security solutions are chosen with the aim not to interfere with applications. Many of them are rather reactive in nature and transparent to the application as they are provided by IT operations or infrastructure.
An application developer would not try to experiment with infrastructure security features and IT Ops people try not to get involved in application complexities. IT operations and IT application development are completely different worlds and current IT governance/management frameworks support this separation of concerns. 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), which is a good thing, however, adding even more risk when IT Security is lacking.
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. Application Security needs a good story and some buzzwords as “Shift Left”, “Design by Security” 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
This is not an article about the dangers of IoT and vehicle IT Security. However, it is clear that conflicting paradigms regarding product safety and IT Security are at work, which will need to be reconciled in order to make sense in the long run.
For the automotive industry regarding providing continuous hardening update services far beyond vehicle end-of-production date as more and more cyber risk are introduced with interconnected IT cars, but on the other hand also for the IT industry regarding “Security by Design” in order to improve the quality of typical IT products when they are shipped. Preventing future product quality and safety issues regarding costly IoT assets is impossible without addressing IT Security during the whole product life-cycle and even beyond – which creates also a tremendous economic challenge for 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 following is a story for promoting Application Security with the help of three buzzwords, one is especially useful for senior management and the other two for the IT people on the ground in the trenches (developers, tester, project manager, IT operations).
Poster: An Application Security story on one page
The story is condensed to a one pager (poster sized, though) and includes many opportunities to discuss Application Security from various angles and contexts. It combines two perspectives:
- The top-down perspective is about sparking interest for proactive and preventive IT Security within senior management.
- The point is that senior management is less interested going into technical details of IT Security solutions but is very responsive when the discussion is about reducing cost and risk. Therefore, the use of “Shift Left” as comprehensive slogan in order to get senior management on board.
- Without support and commitment from senior management, bottom-up security by the people on the ground in real projects is simply not viable.
- Showing the current tragedy regarding the realities about IT Security on the ground during development projects.
- Showing best practice which includes adding IT Security requirements and working with a DevSecOps mindset and supportive tools and processes.
The ideal of preventive/proactive Application Security is to implement 1) the “Security by Design” approach at the very beginning of a development project and 2) ensure a “DevSecOps” type of continuous security hardening during the whole application life-cycle. However, implementing it in the real world is only possible by convincing senior management first in order to provide continuous support and budget commitment.
Missing security is not about bad intentions
The problem with good preventive Application Security is that it can be difficult and costly and that everyone on the ground in the IT trenches knows that commitment and budget is often lacking in this area. It is only natural that the people on the ground try to avoid getting dragged into a difficult battle about security without explicit mandate nor project budget. This is not about bad intentions of application developers or project managers but simply the way how the corporate machinery works on all levels. The tragedy is that even those who would be motivated to act proactive and preventive would also be forced to pursue a reactive approach.
A developer cannot simply add security functionality as he pleases without mandate, that would be risky for the own career. Some security measures are difficult to implement and need ample planning in order to prevent seriously breaking the application, the budget or delivery deadlines. A good project manager would not allow this to happen and require an explicit mandate for Application Security design with additional budget and management support for adding such requirements.
Security requirements should not be treated as other non-functional requirements
Unfortunately, business does not care so much about IT Security as it naturally focuses on functional requirements, i.e. to realize business functionality in the application development project. Security measures are non-functional requirements like capacity or performance planning of which the details are fully delegated to IT. Business expectation is to leave IT specific things to IT, which is normally a good thing, as IT people know best how to deal with IT topics. However, this works not so well for Application Security.
Bottom-Up Perspective: The Reality on the Ground
The Tragedy of Application Security
Unfortunately, the corporate machinery has the tendency to produce the outcome of “kicking the can further down the road” when it comes to Application Security. If business is leaving IT Security to IT (which means the development project), the development project without appropriate budget and resources for Application Security will leave it to what is available within IT operations as IT Security infrastructure, or whatever IT operations is offering in this area. However, whatever it is, it will be a far cry of what would be required on the application layer in the context of ever increasing cyber security threats.
The bottom-up perspective is explained on the background of possible development methods. The left hand side depicts traditional methods (like Waterfall, here the V Model) which are extremely formal, expensive and slow, while the method on the right hand side is extremely agile and delivers extremely fast (due to automation an Agile/DevOps hybrid can deliver on hourly basis).
This is not about development method preferences, this is about having some understanding about the bandwidth of current development methods. In the reality you will always find a hybrid of multiple methods somewhere in-between these two extreme examples, in order to adapt the project to circumstances and context. The point is that some basic understanding about development methods is not only handy but should even be considered an important part of IT literacy. Especially people from IT Security, IT Risk or IT Government departments must be aware about the used method before they get involved. Ignoring the difference between Waterfall, Agile or DevOps will give them a hard time as they risk to get out-of-sync with the project and in the worst case left behind.
Nevertheless, the development method does not matter in order to add or to ignore Application Security during development. What really matters is the mindset within the corporate machinery regarding IT Security. If business officially requires Application Security to be included in a project, then the project manager should know what to do in order to satisfy his stakeholders.
The project manager will integrate security requirements to the formal and structured development process of traditional development methods (like Waterfall or V model), which also means to make sure that there is commitment for additional budget for these requirements. More recent agile based methods give far more leeway to the project manager but in the end it is about ensuring that the delivered product has a consistent security model which can be linked to plausible threat model scenarios.
Criticizing is cheap, changing behavior is hard
This should not end in blaming the developer or the project manager who do not or cannot add Application Security to their project. The message is that Application Security will not work if left to IT alone by delegating responsibilities without giving the means to realize it.
The following depicts two ways to address this:
- “Security by Design” by adding and implementing Application Security requirements
- “DevSecOps” mindset of Continuous Hardening (CH)
Mandate “Security by Design”: Add Application Security requirements
What is required is a small but decisive change within the corporate machinery regarding how to build or introduce new IT solutions. Business or IT governance must trigger this change – which simply means to add an official mandate so that application development projects develop a security design and implement it. Sounds simple but it will only work with additional budget and sufficient management support, i.e. showing real commitment. Business or IT Governance must officially commit and support Application Security; which is actually hard to achieve as it requires a substantial mindset change plus committing resources.
The message to the people on the ground is simple. Make sure you can work on Application Security requirements and that DevSecOps support is available in order to implement security efficiently. If this is not available then you need to try to convince business first.
Mandate “DevSecOps”: Continuous Hardening (CH)
Implementing Application Security is not easy and the application developer could need some help. Triggering the requirement chain in order to officially mandate Application “Security by Design” is one thing. Another thing is how to implement security efficiently as – in fact – security is a rather never-ending story. Continuous hardening is the key word and it is a “DevSecOps” core issue to do it efficiently.
Even if all developers would become security professionals and devote 100% of their time to security (which would leave the question who does the non-security work…), some part of Application Security is still hard and complex to implement. It helps tremendously to support the developer by providing security tools (SAST, DAST, IAST, etc.), coordinating processes (security embedded QA, enterprise security architecture support, pen test etc.) and reusable security functionality within infrastructure (Managed Security Platforms, WAF, RASP, be it cloud based or on-promise etc.) in order to beef up efficiency.
Embedding the Application Security Architecture of a particular solution into an overall Enterprise Security Architecture would be a good approach for long term efficiency. However, such considerations should happen at design time and not just added as afterthought shortly before release. An Enterprise Security Architecture would ideally be available as security infrastructure and provide reuse and cost sharing potential of otherwise expensive application security functionality.
The reuse of infrastructure based security functionality will also depend on its availability to the developer in the various dev and test environments. A developer will hardly bother to experiment with advanced security features on e.g. a WAF which is only available in the production environment. The Ops team on the other hand would not risk to switch on such advanced features out of fear it could break applications. A reuse strategy in the sense of an Enterprise Security Architecture clearly requires cooperation between development and operations teams, ideally making these features also in the dev and test environments available.
Top-Down Involvement Required !
However, what would make business inclined to listen to this and not just continue the old way? After all, leaving it to IT and finally to IT Security Infrastructure seems to be far cheaper without impact on cost and time to market. The point to convince business is having a good story and this is not about explaining complicated IT Security technologies and architectures but having a simple convincing story related to cost and risk.
A useful buzzword for business stakeholders: “Shift Left !”
Business is good in understanding and working with cost and risk implications. As a side thought, maybe this is also the reason why a good hacking demo is so effective because it creates a direct link between cost and risk for convincing even the toughest controller. However, that is already too late.
The “Shift Left” story is about understanding that it is costly to change an application afterwards, and furthermore, that cost increases the later it gets. This is easy to understand if you think about dependencies of all sorts; dependencies in the code, external services, processes and even between stakeholders. Consider it luck if it ends with patching just one simple bug. On the other end it can really get hairy when the whole architecture urgently needs to be changed in order to stay in business.
Keep an eye on the realities on the ground regarding “Shift Left”, “Design by Security” and “DevSecOps”
It makes sense to solve design and security topics during the design phase and test them carefully in order to find issues early and not too late after the release. This is well understood in the physical world with quality control and W. Edwards Deming. However, in IT this paradigm does not seem to apply often because time to market (TTM) became more important than anything else. This will need to change as more and more firms experience cyber security issues, which will also trigger discussions about spiraling cost for adding more and more layers of cyber security point solutions. Remember, cyber security is a never-ending story.
The old paradigm of “Security as Afterthought” is no longer sustainable with exponentially growing risks and costs in the cyber space. Application Security with “Security by Design” and “DevSecOps” type of Continuous Hardening is inevitable.
Keep an eye on the realities of Application Security within your organization and check if motivation and implemention is consistent. It looks like an equation with motivation on the left hand side and implementation of the right hand side: AppSec (“Shift Left”) = (“Design by Security”) + (“DevSecOps”). Implementing Application Security requires strong and continuous support and commitment from senior management in order to become viable.
Author: Roberto Di Paolo
Version 1.2, 2017/08/31 © ACROSEC Inc., All Rights Reserved