To gather insights on the state of application and data security, we spoke with 19 executives who are involved in application and data security for their clients.
Here’s who we talked to:
Sam Rehman, CTO, Arxan | Brian Hanrahan, Product Manager, Avecto | Philipp Schone, Product Manager IAM & API, Axway | Bill Ledingham, CTO, Black Duck | Amit Ashbel, Marketing, Checkmarx | Jeff Williams, CTO and Co-Founder, Contrast Security | Tzach Kaufman, CTO and Founder, Covertix | Jonathan LaCour, V.P. of Cloud, Dreamhost | Anders Wallgren, CTO, Electric Cloud | Alexander Polykov, CTO and Co-Founder, ERPScan | Dan Dinnar, CEO, HexaTier | Alexey Grubauer, CIO, Jumio | Joan Wrabetz, CTO, Quali | John Rigney, CTO, Point3 Security | Bob Brodie, Partner, SUMOHeavy | Jim Hietala, V.P. Business Development Security, The Open Group | Chris Gervais, V.P. Engineering, Threat Stack | Peter Salamanca, V.P. of Infrastructure, TriCore Solutions | James E. Lee, EVP and CMO, Waratek
Here's what they told us when we asked them, "What do developers need to keep in mind when working on application and data security?"
- Get application security training. Produce and learn the product. To be a qualified engineer think about failure and work to build resilient applications. Software developers don’t get exposure to security in schools. Your code will be used in ways you did not intend and it will be targeted. It will be on the internet and it will be exposed. Validate and authenticate to prevent it from being hacked.
- See the requirements and the strength of the app to ensure it cannot be hacked or stopped. Protect access to the data. Provide security on a REST API to leverage third party applications. REST API securely moves data back and forth.
- Have a knowledge of frameworks. Monitor the performance of your applications for unusual or unintended use. Follow OWASP (open web application security project) and WASC (web application security consortium) for web apps and CWE (common weakness enumeration) for mobile apps. Learn how to address vulnerabilities and attacks.
- Incentive to push out production. Be secure and find bugs. Developers need to push out products with fewer bugs. Iterate on those concepts. Have a quicker security feedback loop. Do more earlier during the security process.
- Whatever platform you subscribe to know the vulnerability tests. Subscribe to the list that lets you know of every vulnerability (CVE) related to your field and stay up to date on patches. Mitre is a good site to keep track of vulnerabilities.
- Developers don’t need to be to clever. Don’t reinvent the wheel. Identify the best practices and follow them. Read, be an active consumer, hone your craft. Be vigilant and active.
- Be aware of threats and design principles. Know the OWASP top 10 and vulnerabilities databases.
- The attacker will not introduce themselves to you. Validate every piece of data you receive. Sanitize all inputs.
- Look at the application and think of ways to hack. Build quality in. Depend on the tool chains and the effects on code. Question the security implications to what you are building. There are large architectural issues and small things. Some is cultural. We have one client that has posters up where their developers work reminding them about privacy and PII. We need to be constantly vigilant with ongoing education and reminders.
- OWASP 10. Shift security left in the SDLC. Live security procedures and processes. Do not just view security as an add on after the fact at the beginning.
- Developers receive very little training in security and it’s an afterthought in the development process where the emphasis Is on time to market, not security. Product management needs to treat security as an important feature of the product. Security needs to be designed in from the beginning. Products have become more complex due to the architecture.
- Think about security holistically and earlier in the development process. Agility is required in DevOps. Additional layers of security result in fewer intrusions. The more intuitive you are; the better solutions you will create. Be aware of configuration requirements and rules. In the event of a breach, admins are the first to be investigated. Developers and testers need to be able to do their job without access the data.
- Developers need to understand there’s not a big difference between a bug and a vulnerability. You must measure at the same level of understanding. Greater career ops for developers with secure coding skills. More skills equate to greater career growth. There are many advantages to being a secure developer and there are a lot of tools to understand/learn secure coding.
- The natural tension that has almost always existed comes down to competing goals. Developers are incented to bring an app in on time, on budget and to perform at max efficiency. App Sec teams are incented to make applications bullet proof, a requirement that more often than not results in a significant performance overhead. Fortunately, newer tools like RASP by virtualization do not slow app performance and are highly accurate. Results like that take away the natural tension and allow for more collaboration.
- Challenge teams to define the role of security in the product and the company. Look for deterministic answers. Integrate security early. How to introduce workload-focused security? The more you know earlier in the SDLC the better off you are. If you are doing DevOps engineering, you are in a better position to enact changes in security. We need to make it easy for developers to develop securely and to see how their workload is performing.
- Test with real data in a production environment. Automate to see holes early in the process. Testing is moving left. Security testing is treated separately. It’s not integrated into the DevOps pipelines and it needs to be. We need to have a security mindset. As containers evolve, Docker has an opportunity to put the focus on security due to their isolation and protection.
- Understand and keep in mind the end two end use cases and implications. Developers should not be just focused on creating a specific module or component. In a lot of cases, security considerations are looked at the end of the process only. If developers are involved security is seen as a pain rather than helping. Both sides have to make sure they come closer together and work on a common solution which incorperates security.
- Secure coding best practices. Static and dynamic testing. Trust no environment. Whatever you’re running has full visibility for both distributed and cloud versions. You cannot trust runtime any longer. Understand security at runtime. It’s good to use standards as your baseline and then go beyond them. The difficult part is the hacker knows all of the angles. You need to know assembly and high-level programming languages. Help the security team to be holistic.
- Do your homework before you begin development. Understand vulnerabilities and what to avoid. Do any preplanning you can.
What suggestions do you have for developers with regards to application and data security?