This is part II of the Application Security story. Follow this link to part I in case you need a broader introduction.

Many 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 during application development. Why is that so and what needs to change in order to advance Application Security?

The Application Security poster is an attempt to promote the three essential elements for improving Application Security. “Shift Left” is especially useful on level senior management, while “Security by Design” and “Continuous Hardening” relate to concrete actions and tools in the IT trenches.

The intended audience is 2-fold: “Top down” C-suite stakeholders and “bottom up” technology stakeholders from the ground in the IT trenches (developers, tester, operations, project and IT managers, but also people from Infosec, IT Risk and IT Governance).

A CEO who is successful in the IT industry is probably already familiar with about 80% on this poster. The same should be said for experienced IT personnel, so we have a large overlap which can be useful.

The problem is that Application Security is notoriously difficult and tends to end in a lot of technical detail discussions. Take the famous OWASP Top 10 list of vulnerabilities. Very important but certainly not an area where senior management can contribute. However, it should be of concern to senior management why the current OWASP Top 10 looks awfully like the version from 10 years ago, or even when it came first out in 2003. What are the mechanisms in many organizations that lead to the impression that we don’t really advance here? What are the root causes? What needs to change to make progress in Application Security?

A good CEO would certainly want to understand the realities in the IT trenches if he/she perceives that Application Security might be important, especially if there is potential for repercussions on the business strategy. The purpose of this poster is that “top down” and “bottom up” stakeholders could have a more focused discussion if they use it as mental guide when discussing the most important mechanisms for making or breaking Application Security within their organization.

Shift-Left, Security by Design and Continuous Hardening — Figure: A poster for promoting Application Security with three useful concepts (“Shift Left”, “Security by Design” and “Continuous Hardening”) in order to provide visual background for discussing Application Security from various angles.

Download

It’s probably a good idea to pause here for a moment. Download the poster and have a look at it over a coffee before you continue with the explications below.

They poster comes in 3 sizes (A3, A2 and A1). A2 size is probably best suited for a discussion at the desk. A3 size is still workable but you need a good printer for the fine print (and a good vision, too). The A1 version is for the main purpose of a poster; hanging at a wall.

The poster is strictly product neutral and published under a Creative Commons license for better sharing (CC Attribution-NonCommercial-NoDerivates 4.0).

Overview Application Security Story

The Application Security poster contains many opportunities to discuss Application Security from various angles and contexts. Seen from the top, it combines at least 3 perspectives:

The title section: “Shift Left”, “Security by Design” and “Continuous Hardening” as most basic key concepts for Application Security. Understanding them is essential for effectively handling Application Security.

“Shift Left” section in the middle of the poster as “top-down” perspective:

This is essentially about engaging senior management. Senior management is usually not so interested in technical detail discussions but might be very responsive on the other hand, when the discussion is about reducing cost and risk when it matters for the business. It might be useful to remember some “too little, too late” examples which brought down whole companies.
Senior management support is absolutely required for realizing a more proactive security approach. “Bottom-up” driven security from and by the people in the IT trenches is not viable and completely moot without continuous support and commitment from senior management.

The “bottom-up” perspective covers the whole lower half of the poster. It’s about the people on the ground in the trenches and their relationship to IT Security within application development projects. It presents two views:

The tragedy in the IT trenches as often seen reality in development projects when security is just an afterthought.
A proactive, better approach which includes “Security by Design” and a mindset of “Continuous Hardening” including supportive tools and processes.

The ideal of a preventive more proactive approach towards Application Security is to get started with 1) “Security by Design” at the very beginning of a development project and 2) to ensure continuous security hardening from development to end of life during the whole application life-cycle.

Clearly, such an additional effort requires motivation of the decision makers. It’s only possible when senior management provides continuous management support and commits adequate budget.

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 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 there is no 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 proactively add 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. This is about requiring to include security requirements at the very start of a development project.

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 of an application development project is to realize business functionality. 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 when it comes to Application Security. It might be a good approach to treat security as part of product quality because there are a lot of similarities!

Bottom-Up Perspective: The Reality on the Ground

The tragedy of Application Security

Criticizing and blaming is what normally happens next after vulnerabilities are discovered or incidents happened. However, criticizing is cheap, changing behavior is hard. It’s a systemic problem but it often ends by blaming the developers who did not (or could not) add adequate security. Clearly, Application Security will not work by delegating responsibilities without giving the means and resources to realize it.

Unfortunately, the corporate machinery has the tendency to reproduce the outcome of “kicking the can further down the road” when it comes to security. If the business sponsor is leaving security to IT (which means the development project), then the development project without an appropriate budget and resources for Application Security will leave it to whatever is available 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. Truly a tragedy!

Figure: The reality of IT Security in many application development projects. This happens independently of the development methodology because the problem is missing security mindset and missing commitment.

The “bottom-up” perspective of doing development in the IT trenches 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 which is depicted here as being on steroids due to the Dev/Ops automation pipeline attached. 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 in this picture. The same can be said for other current development methods or hybrids. Consider them as being placed somewhere between these two extreme examples, which are just the opposite ends of a larger universe of development methods.

The intent here is not to discuss development methods preferences. The poster goes into some detail because it’s important in relation to security to grasp the gist of current development methods. The issue is to catch the right moment when IT Security issues should be addressed during a project. Bear also in mind that hybrids or mixtures of multiple development methods are common, because of context and individual project circumstances.

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.

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.

Mandate “Security by Design”: Mandate to include 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 are in a good position to trigger this change – which simply means to add an official mandate so that application development projects develop a security design and implement it. This will only work with additional budget and sufficient management support, i.e. showing real commitment.

In order to get there, senior management needs to officially commit and support Application Security. In the end, it requires a substantial mindset change on many levels plus committing the resources for it.

Figure: Moving towards proactive and preventive Application Security

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 support for Continuous Hardening is available in order to implement security efficiently once when the security design has been determined. If the basics are not available then you need to convince first the business sponsor to get proper support and budget.

The project manager will then integrate security requirements to the formal and structured development process of traditional development methods (like Waterfall or V model). More recent agile based methods give far more leeway but in the end it is about ensuring that the delivered product has a consistent security design which can be linked to plausible threat model scenarios.

Now that the requirement chain has been triggered with an official mandate for “Security by Design”, the next step is to implement it.

Mandate “Continuous Hardening (CH)

Design work is ideally a one time effort. Besides that, there is a completely different type of work which is about incremental improvements. This happens within a chosen design and is a repetitive, continuous effort in order to improve gradually the product until it is ready.

Obviously, the more improvement cycles, the better the chances to have a great product. This typically happens during development, but there is also room for incremental improvements even after a release, think in terms of product updates or bug fixes. In terms of security, this is called hardening. Doing it continuously (“Continuous Hardening”), efficiently and effectively should be the goal.

However, security is a rather never-ending story and implementing Application Security is not easy. In short, the application developer could need some help.

Why could the application developer need some help? Imagine an ideal world where 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, but anyway). Some parts of Application Security are still hard and complex to implement. Hardening activities can happen before and after a release. Scanning the code base for security issues is a hardening example. Creating a security patch which corrects one single typo is also a hardening example.

Obviously, doing “Continuous Hardening” after a release requires to have the development and test environments ready even years after the end of the development project. A no-brainer in the context of DevOps (DevSecOps) style environment for Continuous Delivery, however, security hardening should also happen in non-DevOps projects.

Furthermore, many security decisions base on interpretations of current knowledge. Getting to the point of depth knowledge, experience and expertise is a long process. A further dependency is their implementation context which is related to specific use cases, currently used technologies, 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.

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 an afterthought. A focus on Enterprise Security Architecture would ideally result in useful security infrastructures, 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 development and test environments. A developer will hardly bother to experiment with advanced security features on e.g. a WAF when it’s only available in the production environment.

The Ops team on the other hand would not risk to activate advanced application security featstyleures 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 development 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 about cost and risk related to their business. Discussions on this level are not required to go into the details of security technologies. It would be not only be a challenge in itself but also risks to derail the whole discussion.

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 can be so effective. It will convince even the toughest business person if a direct connection between cost and risk can be established.

The “Shift Left” story is especially about raising the attention of senior management to the whole application life cycle. Particularly about understanding that it’s 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.

Why this focus on senior management? Because it’s related to balancing the short term and long term business perspective, which is handled on top corporate level and nowhere else. It’s not enough to convince IT engineers or middle management. They will have to follow the general direction and constraints which are decided at the top. If the mood is rather on a short term quarterly agenda, then middle management will not have much room of maneuver regarding long term security goals.

Figure: Security as an afterthought becomes costly and risky the later it gets to correct a problem.

Risk, cost and remediation effort rise the later incidents happen in the application life cycle. This is due to 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. Obviously, there is also the risk of over-engineering, so the goal should be to have a robust enough design for the purpose at hand.

Figure: A good reason to support and commit to Application Security.

“Shift Left” as motivation driver
Application Security does not happen in a vacuum. Implementation and motivation for Application Security are related and can be expressed as equation. A meaningful implementation requires that someone has a stringent motivation for it with enough funding and powerful backing 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” + “Continuous Hardening”) = AppSec motivation (“Shift Left”)

Message: Keep an eye on the realities on the ground regarding “Shift Left”, “Security by Design” and “Continuous Hardening”

It makes sense to resolve design issues during the design phase, and implementation issues during the coding and build phase, which also means thorough testing in order to find and correct issues early and not when it is too late. 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 blow back risks to all other industries and businesses which rely on IT.

This will need to change. 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 costly 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 a 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 “Continuous Hardening” as these three elements are essential. Application Security requires strong and continuous support and commitment from senior management in order to become viable.