Guest post by Neil Correa, Micro Focus Solution Architect
<Application security is gaining more and more visibility from the good guys and bad guys alike. Unfortunately the bad guys highlighted the need before the general population realized it was a previously unidentified risk area.
Let’s start with the basics, good cyber security risk mitigation can be broken down into three main steps:
- Identify what’s important to the organization (systems, data, and networks);
- Determine the risk level that is acceptable to the organization (zero risk is not achievable);
- Deploy controls to reach the acceptable level.
This is a tried and true approach and is great at identifying what an organization cares about and how to ensure it is kept safe. This list of items usually cover IT infrastructure that are required by the business in order to function, network availability, IT security systems and any compliance related systems (think PCI-DSS). This is a pretty good list and will usually cover 60% of the important items but it’s the other 40% in which security teams aren’t even aware. The true risk to any organization resides with the business, it’s really the data and the processes, systems and applications that provide access to the data that hold the real risk. A typical security team is only aware of the risks associated with the network and infrastructure layers, leaving a gap in the protective controls at the application and data layers.
For now, let’s focus on the application layer as this is the primary method to gain access to data that resides in data repositories such as databases and data lakes. Usually this is out of scope for most security teams, not due to a lack of accountability (a security team is responsible for securing the full network – systems, infrastructure and applications) but a lack of understanding of the business or unfortunately, an incomplete review of risks. The risks with applications, mainly web facing, are high for the following reasons:
- If commercial/open source software – Similar to commercial operating systems, the ability to attack multiple targets with the same vulnerability makes it worth the effort for any level of hacker;
- If legacy (old) software – New and old exploits can be used against systems that have not been patched (or even supported?) for a very long time;
- If custom/in-house software – These are usually project based developments, meaning short-term developers are hired who have various levels of application security knowledge. Most organizations don’t have application security as a priority when planning application development in the first place.
If we were to take a DevOps approach to software development, within a few days to weeks, a software application has been developed and deployed into production for a business critical function, oh and it is web facing and will be collecting a little bit of personal information such as social security number, first name, last name, home address, medical history, credit card number, gender, medical insurance information, etc. Not too bad right? The DevOps team thinks, we know there might be risks associated with this application but part of our process is to perform a pentest semi-annually so we’re covered. Security concerns? No, there shouldn’t be anything to worry about, we have hardened web servers and also our semi-annual pen test. Privacy concerns? Well, we performed a Privacy Impact Assessment (PIA) and know that each person providing this information will be giving their consent before we are able to collect this information.
Does that sound familiar? Anyone else losing their hair (or something else) right now?
The ideal method to reduce application security risks would be to bake in application security to your DevOps processes however, given that DevOps organizations deploy to production at the speed of light, there may not be enough time to secure the projects currently in flight (using products like Fortify Static Code Analyzer, or Fortify WebInspect which easily integrate into a DevOps environment). This project must meet its go-live timelines and any issues will be dealt in future releases. Fortunately Runtime Application Self Protection (RASP) technology was developed to fit this exact requirement!
Imagine finding out that your super-awesome application, collecting all this great data for your own use (in alignment with all of your privacy and compliance requirements of course) that will help your company outperform the competition is now secured against hack-attacks so that your data won’t end up on the Dark Web or be used to blackmail your organization. This is the best of both worlds!
RASP technology is a great solution to mitigate a previously unknown risk to an organization. The bad guys are increasingly aware of vulnerabilities at the application layer and take every chance possible to exploit vulnerabilities and get access to the underlying data. Recent reports attacks happen at the application layer. Given the success rates of such attacks, this number isn’t going to decrease anytime soon.
Micro Focus Application Defender (AppDefender) is a leading RASP technology. It includes over 60 Logging categories out of the box such as File Read/Write, HTTP Sessions Start/Stop, User Activity, etc. Additionally AppDefender has the ability to monitor/block vulnerability exploit attempts and other security violations. It also includes over 30 Vulnerability categories that can be monitored or protected on the fly. With capabilities like this, security will enable organizations (securely) instead of being a pain in the bottle-neck (get it?).
Hope this short article was informative, helpful and enlightening. As always, constructive thoughts and comments are welcome.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.