The old habit in application development of dealing with security as just an afterthought is not sustainable. Spectacular incidents propagated in the media help to spread the word and put businesses under pressure to improve. It already has improved in some high profile business areas (e.g. banking and finance) and in some countries which are more IT Security aware. However, this habit is sticky for many reasons.

It might be a good idea not only to focus on IT Security technicalities but also to address what might hamper the proliferation of IT Security. There might be organizational issues and resource problems. Insufficient application security hints at a lingering cost problem within IT management.

Making changes at the end of a development project is not only too late for security, it gets also more costly the later such changes are introduced, especially when the application is already deployed. An application has running costs of roughly 15%-20% of the initial application development project costs just for operation and maintenance per year. It would therefore be better to calculate cost/benefit for the whole life-cycle. Additional security changes add up cost and some serious IT changes might even require to start a dedicated change project. You get the picture.

The best approach for cyber security is to cover security during the whole application life-cycle end-to-end. It begins at the very start of the development project, covers all operation cost and should also include decommission efforts. This is expressed as TCO (total cost of ownership) and applies regardless of delivered functionalities, or development methodologies. The intent of specifically including some notoriously difficult non-functional requirements such as IT Security can be caught with two simple but powerful slogans: “Shift Left” and “DevSecOps”.

These management friendly buzzwords are very helpful for conveying the idea that secure application development and operations in the cyber security area requires a shift of mindset.

Does everyone now need to become a security professional?

Better application security requires a paradigm shift, especially in countries or areas, where IT Security is traditionally left to network operations or infrastructure departments.

Developers are also responsible for the security of their applications and need to do more. However, as true as this is it should not lead to a “kicking the can further down the road” situation by passing all the responsibilities to developers. It would not be fair without further considerations because robust application security is really difficult to achieve:

Application security is by far the widest area in IT Security and some parts of it are complex and require professional level of IT Security know-how in order to do it correctly.
It is not possible to quickly turn all application developers, tester or engineers into IT Security professionals.
Application security can be implemented in many different ways on many different layers.
Project members of different development project will always interpret and implement security requirements differently well. They will also most probably use different programming frameworks for implementing security on different technology layers in different ways. This results (unintentional) in different exposure profiles across the application, thus unintentional different protection and security levels in the application portfolio.
Some applications have long release cycles for dependency reasons and cannot be changed quickly.
Testing is a tedious task and very time consuming. This will not become better with additional security testing and code reviews.
Infrastructure and operations departments do not wish to become involved and responsible for application security and do (naturally) not implement such security features – or not strictly enough as it would be too invasive.
Application developers and business owners mistakenly believe that security is already covered by infrastructure. Misunderstandings based on unverified assumptions and expectations are frequent in IT which is especially bad when it gets important like with cyber security.

These problems need to be addressed in a smart way. This means for DevSecOps to clarify who does what on which (security) layer.

How much DevSecOps? How much “Shift Left”?

DevSecOps is a mindset how to include security into the development and operations life cycle. It is however an open discussion what should all be included and count as DevSecOps. If you just look at the semantics it could also be SecDevOps and DevOpsSec, but this is not used yet and there are better words to express its meaning.

There are at least three phases which should be distinguished in such a discussion:

Security process before starting to code (security design)
Security process during coding (security hardening)
Security process after coding (security patching after the release)

The “security as afterthought” mindset can also happen within DevOpsSec. If DevSecOps is taken lightly it might just be used after a release. Using vulnerability pen testing is then just a better variation of the “security as afterthought” pattern.

“Shift Left” is to express how far to move from this “security as afterthought” towards integrating security really into the development process. DevSecOps is the terminology supposed to express that. However, there is also DevOps, and if it is used in this sense, then it risks to be somewhat limited to what happens between developers and operations. It ideally should include also the requirements and design phase.

It makes sense to shift as far left as possible in order to bake security into the end product because some design and architecture decisions are difficult to change afterwards. SecDevOps would be a good word to express that but it is not an accepted terminology and instead of getting lost in semantics, it might be better just to say what is needed, namely “Security by Design”. The distinction between “Security by Design” and “DevSecOps” is useful in order to prevent misunderstandings.

Whatever the definition is, it should be locally decided how far “Shift Left” is possible. This is a call for senior management because it is an IT governance and strategy issue how far to go on this road. DevSecOps based technologies and services can then support projects to achieve security and quality goals more efficiently.

Web application example: Supporting “Shift Left” and “DevSecOps” with a versatile WAF

A good reverse proxy is for web application security and also for web application delivery an essential element. Using a solution like the Airlock WAF as security framework with staging support makes these security standards directly and practically available to developers and operations which is good for efficiency. Next step is then to clarify the DevSecOps responsibilities as how to actually use these security standards within the organization:

Developers should not develop complex security features but just reuse the Airlock standards (central authentication and SSO, access control, secure session handling, secure cookie handling, URL encryption, form protection, browser fingerprinting etc.).
Developers should only develop application specific security features (data access control, application business flow and transactions, protecting the application APIs, exceptions, etc.) which cannot be reused and focus on improving their code quality (security testing, code scanning etc.).
Operations use Airlock WAF features for patching newly discovered vulnerabilities centrally – or readjusting the security level centrally for all or the relevant applications.
Infrastructure uses Airlock WAF as secure reverse proxy for DMZ security and application delivery (load balancing, fail-over and high availability, network segregation, URL redirects and content rewrites etc.).
DevSecOps with Airlock results in a consistent security infrastructure for web applications and in secure web application development. Such a framework strategy can be executed on premise or in the cloud.

The above was just an example of how technology and better organization interaction helps in realizing DevSecOps for cyber security. This thinking can be applied also to other technologies or products for embedding it neatly in DevSecOps. However, there is more to it.

It makes also lot of sense from the IT strategy and business point of view. It is good to reuse what is difficult to implement by fostering standardization or to automate what is time consuming to do. Therefore combining cyber security with efficiency. However, it still needs the element of who should do what on which layer.

Realizing an Enterprise Security Architecture for web applications

The above WAF example is interesting as it is also a secure reverse proxy which is versatile enough for covering many other aspects in web application delivery.

Leveraging a secure reverse proxy as central entry point for all web applications has potential of strategic importance when it is made part of the overall cyber security concept.

Such an overall concept would be the realization of an Enterprise Security Architecture for all Internet facing web applications with many positive implications for business application strategy, IT Management and IT Governance. This example should make it clear that project based “Security by Design” requirements and Enterprise Security Architectures requirements are closely related.

Mandating the reuse of what is difficult to implement by individual developers and by making such standardized features centrally available improves not only cyber security, but it also increases overall cost efficiency of running web applications securely.

Author: Roberto Di Paolo