This is part II of the Application Security story. Follow this link to part I in case you need a broader introduction.
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. Why is that so and what needs to change in order to promote Application Security?
The following is an attempt to promote discussion regarding the three essential elements for improving Application Security. 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 and also for Infosec, IT Risk and IT Governance).
Poster: An Application Security story
The Application Security story is condensed to a one pager (poster). It contains many opportunities to discuss Application Security from various angles and contexts. Seen from the top, it combines at least two perspectives:
- The top-down perspective is shown as grey area in the middle section of the poster and 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 when it really matters for the business. 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 in the IT trenches in real projects is not viable.
It presents two views:
- The often seen reality about IT Security (the tragedy in the IT trenches on the ground) during development projects.
- A suggestion for a better approach which includes “Security by Design” and a “DevSecOps” mindset including supportive tools and processes.
The ideal of preventive/proactive Application Security is to get started with 1) “Security by Design” at the very beginning of a development project and 2) to ensure a “DevSecOps” type of continuous security hardening during development and after release during the whole application life-cycle. It is clear, that such an additional effort requires motivation of the decision makers. It will be only possible when senior management gets convinced to provide continuous management support and adequate budget commitment.
Equation for Application Security:
Application Security does not happen in a vacuum. Implementation and motivation for Application Security are related and can be expressed as equation with implementation on the left hand side and motivation on the right hand side (or vice versa). A meaningful implementation requires that someone has a stringent motivation for it which is financially funded and powerful enough to overcome the many hurdles:
AppSec implementation (X) = AppSec motivation (Y)
Following equation shows the intention of the Application Security poster:
AppSec implementation (“Security by Design” + “DevSecOps”) = AppSec motivation (“Shift Left”)
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. People will try to avoid getting dragged into a difficult battle about security it they do not have an explicit mandate nor project budget for it. This is not about bad intentions of 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 proactively and preventive would also be forced to pursue a reactive approach.
A developer cannot simply add proactively security functionality as he/she pleases without mandate (not a smart move career-wise). Furthermore, some security measures are difficult to implement and need ample planning and testing in order to prevent seriously breaking the application, the project 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 but more like quality
Usually, business does not care much about IT Security but about functional requirements as the goal is to realize business functionality with an 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 the IT department, 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 the business sponsor 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 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.
The bottom-up perspective is visualized with the two most extreme 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.
The word “agile” is used here as generic placeholder of such development management methods/frameworks. However, in case you need a more concrete picture, think of it as Scrum (or whatever you like) which is depicted here as being on steroids due to the Dev/Ops automation pipeline attached to it. Such an Agile/DevOps hybrid can deliver on hourly basis due to automation. Note, that the outcome (security tragedy in the IT trenches) is the same for both traditional and agile methods on the picture. The same can be said for all other current development methods as they can be considered as mixture somewhere between these two extreme examples.
The intent here is not to discuss development methods preferences. Nevertheless, the poster goes into some detail because it is important to grasp the gist and the bandwidth of current development methods in order to catch the right moment when IT Security should be addressed. Bear also in mind that hybrids or mixtures of multiple development methods are common in order to adapt to project circumstances and context.
The point is that some basic understanding about development methods is not only useful 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 which method or process is used on which time frame before they get involved. Ignoring the difference between Waterfall, Agile or DevOps will give these stakeholders a hard time because they risk to get out-of-sync with projects and in the worst case left behind.
As noted above, the development method does not matter when it comes to adding or ignoring Application Security during development. What really matters is the mindset and the processes 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/her 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
It seems almost impossible nowadays not to find security flaws in applications. Criticizing and blaming is what normally happens next. However, if there is indeed a systemic problem within the whole IT industry then it should not end in blaming the developer who did not or could not add Application Security. The message is that Application Security will not work by delegating responsibilities without giving the means and resources to realize it. Treat IT Security as part of product quality!
The following depicts ways forward how to address this:
- “Security by Design” – create a security blueprint before actually starting to code!
- “DevSecOps” – implement the security hardening basics while coding (development phase)
- “DevSecOps” – improve security hardening after product release (maintenance phase)
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 together with IT Governance must officially commit and support Application Security, which is 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 a project can work on Application Security requirements before even starting to code. Make also sure that DevSecOps support is available in order to implement security efficiently once you know how the security design should look like. If the basics are not available then you need to convince first the business sponsor to get proper support and budget.
Mandate “DevSecOps”: Continuous Hardening (CH)
Now that the requirement chain has been triggered with an official mandate of Application “Security by Design”, the next step is to implement it efficiently and effectively. However, as a matter of fact, security is a rather never-ending story. Continuous hardening during development and after release is the key word and it is a “DevSecOps” core issue to do it efficiently. Implementing Application Security is not easy and the application developer could need some help.
Why is this important? Imagine for an instance that all developers would become security professionals over night and devote 100% of their time to security (which would leave the question who does the non-security work). Some parts of Application Security are still hard and complex to implement.
Furthermore, many security decisions are interpretation based and have their own implementation context which is related to specific use cases, technologies and IT environments. Creating and maintaining consistency of security implementations across all those different projects, products and IT technologies within the same enterprise can be a huge challenge. It helps tremendously to support developers 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 security efficiency and effectiveness.
Embedding a particular Security Design of a Solution Architecture 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 result in useful 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 when it is only available in the production environment. The Ops team on the other hand would not risk to activate advanced application security 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 available in the dev and test environments.
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. A good approach is to convince business stakeholders with a good story that makes business sense related to cost and risk. At this level it is not required to go into the complicated details of IT Security technologies – which would be a challenge in itself.
Useful concept 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 the whole application lifecycle. Especially about understanding that it is costly to change an application afterwards, and furthermore, that cost increases the later it gets. In some situations it might even get so overwhelming that cost and risks threaten to break the whole business.
This happens because of dependencies of all sorts; dependencies in the code, external services, processes and even between stakeholders. Consider it luck if it ends with patching one simple bug. On the other end, it can get really hairy when the whole architecture urgently needs to be changed in order to stay in business.
Message: Keep an eye on the realities on the ground regarding “Shift Left”, “Security by Design” and “DevSecOps”
It makes sense to resolve security design issues during the design phase and security issues due to bad code during the coding phase, which also means thorough testing in order to find and correct such issues early and not when it is too late after the release. This is well understood in the physical world regarding product safety or product quality (e.g. total quality control – W. Edwards Deming). However, in IT such paradigms do not seem to apply often because “Time to Market” (TTM) became more important than anything else – which creates blowback risk for all other industries and businesses which rely on such ICT technology.
This will need to change as more and more businesses experience cyber security issues, which will also trigger discussions about falling consumer confidence and about spiraling cost as more and more layers of cyber security point solutions are added. Remember, cyber security is a never-ending story and without long term plan it might well become a nightmare. Application Security does not happen automatically and as such is similar to product quality.
The old reactive paradigm of “Security as Afterthought” is no longer sustainable with exponentially growing risks and costs in the cyber space. A more proactive Application Security approach 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 implementation is consistent regarding “Shift Left”, “Security by Design” and “DevSecOps” as these three elements are essential. 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, last update 2018/4/23, ©ACROSEC Inc., All Rights Reserved.