The old habit in web application development of dealing with IT Security as just an afterthought is not sustainable. Incidents which are widely propagated in the press help to spread the word and put businesses under pressure to improve. It already has improved in some high profile IT Security aware business areas (e.g. banking and finance) and in some specific countries. However, this old habit still remains for many reasons. It might be a good idea not only to focus on IT Security but also to address other concerns, as insufficient application security reveals also 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. Considering the application during its whole life-cycle, an application has running costs of roughly 15%-20% of the initial application development project costs just for operation and maintenance per year. Addional security changes add up and having some serious 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; which starts during the development project and covers also operations from deployment until and including decommission. This simply is TCO (total cost of ownership) and applies regardless of delivered functionalities or development methodologies like waterfall or agile type. However, the intent of specifically including some notorious non-functional requirements such as IT Security can be caught with one recent simple slogan: “DevSecOps”.
Does everyone now need to become a security professional?
Better web application security requires a paradigm shift, especially in countries like Japan, where IT Security is traditionally left to network operations or infrastructure departments.
Developers are also responsible for the security of their web 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 individual developers. It would not be fair without further considerations because robust web 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 IT Security professional level 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.
DevSecOps is a mindset how to include security into the development and operations life cycle. However, technology can support DevSecOps to achieve its goals more efficiently and senior management can support it by requiring it to get adequately and efficiently organized.
Just an example： Support 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.
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
Version 1.03, 2017/02/6 © ACROSEC Inc.