After speaking at Qualys’ recent webinar “Aligning Web Application Security with DevOps and IoT Trends,” Forrester’s Amy DeMartine granted us this Q&A, where she revisits and offers keen insights on issues including IoT security challenges and DevOps’ benefits for secure app dev. DeMartine, a Principal Analyst focused on security and risk professionals, also discusses “red teaming” for cloud products, and identifies signs you need a new automated security analysis tool.
Why aren’t internet-of-things (IoT) companies doing more for the security of their products and ultimately their customers?
IoT products and services are being developed very rapidly. Many times security isn’t a buying criteria for the consumers and, therefore, is not a design requirement for the developers. These IoT products and services are often the new, cool technology that consumers are trusting implicitly. Unfortunately, it often takes a security breach or incident to create awareness that products are not secure and raise the awareness of security flaws with consumers.
Why is DevOps a better solution from a security perspective?
DevOps teams create a continuous delivery pipeline that automates the software delivery life cycle. Security pros can use this pipeline to add automated security tests, return output to developers to give them actionable data as early in the life cycle as possible, and add automated security gates. This methodology of adding automated security testing in the continuous delivery pipeline results in applications that expose fewer vulnerabilities at a smaller development cost. Also, because these teams can deploy fixes quickly, DevOps teams can rapidly fix newly discovered vulnerabilities and limit their exposure to malicious attackers.
What can a consumer do to help?
Consumer products will only get better security when consumers demand it. Consumers should ask pointed questions about security features during the sales cycle and from support. And finally, consumers will need to add security to their buying criteria.
Are there any differences in best practices with regards to “red teaming” when your product or service is in the cloud?
In general, red teaming practices are the same whether or not your product or service is in the cloud. For example, the blue team will defend and the red team will attack. The blue team is restricted to using only tools that are in use in the production environment, while the red team can attack with any means. When you have a product or service in the cloud, there might be extra attack surfaces for the red team to test, and the blue team will need to monitor such as database connections from the cloud application back to on-premises data centers. Also, red teams will want to test any cloud services for configuration misconfigurations.
At times, automated security analysis tools generate huge lists of risks, and some of them are hard to understand. How do we decide what the optimum level of fixes is and which ones we should make? And how do we explain the importance of this to other teams when we ourselves might be a little confused?
First, focus on applications that contain the most risk. Risk can be calculated lots of different ways, but an easy calculation is “business impact” multiplied by the number of critical/high vulnerabilities, where “business impact” is determined by how critical the application is to the business or the level of sensitive data it contains. Now that you have the prioritized list of applications, explain to the other teams your calculation and the reasoning behind it. Second, now that application priorities are set and explained, use the output from the automated security tools for the top applications and prioritize vulnerabilities by severity. Most application security analysis tools will do this for you. If you have an automation security analysis tool that generates lots of “noise” in its risks and makes it hard to understand what the most critical vulnerabilities are, it’s time to go shopping for a new tool.
Download this checklist of best practices to save time and understand what to look for when selecting a WAS solution.