IAST: Interactive application security testing. Monitoring an application for security vulnerabilities while it is running — at testing time.
RASP: Runtime application self protection. Monitoring an application to detect attacks while it is running — at production time.
IAST and RASP are security tools that look for issues while an application is running. In the case of IAST, it scans for vulnerabilities as part of the testing process. RAST meanwhile, looks to detect attacks in the production environment.
Software scanning tools that detect vulnerabilities and attacks in real time.
They provide a quick and effective way to improve the security of your enterprise applications.
To use the tools effectively, you need security and software teams to collaborate. This can create a culture shock for some organizations.
These tools are often deployed by teams using microservices architecture.
What is it?
IAST tools install instrumentation code, called an "agent," to monitor an application as it runs and checks for security vulnerabilities. The agent gathers data inside the program that can detect security vulnerabilities that have otherwise been ignored.
RASP follows the same strategy as IAST when installing an agent inside the application; the distinction is how it is used. The IAST tools search for vulnerability bugs, while the RASP looks for signs of an attack, and when detected, defends the application from that attack.
The RASP does not influence the architecture of the program. It provides a security layer to the deployment application, reviews any APIbeing executed, and decides whether or not a given API is potentially a weakness or an attack.
Both IAST and RASP are considered second-generation technologies, that produce lower false positives/negatives than older approaches of testing applications and environments for vulnerabilities.
What’s in for you?
Both IAST and RASP can reduce your risk of disruption or data loss in the event of an attack.
They also give your software teams more in-depth knowledge of your systems. They provide your teams data for fast root cause analysis and correction when problems inevitably arise.
What are the trade offs?
They put Increased responsibility on developers to use the tools correctly. This often means security and developer teams should integrate and collaborate in a concurrent way. We think this is a good thing but it can be a culture shock for some organizations.
How is it being used?
It is increasingly being used to build security into a development environment and is important for a safe and successful delivery.
Would you like to suggest a topic to be decoded?
Just leave your email address and we'll be in touch the moment it's ready.