Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How Devs Can Improve Security (Part 2)

DZone 's Guide to

How Devs Can Improve Security (Part 2)

In this final part of a three part series, we discuss what security professionals from across the industry believe security teams can do to better ensure the integrity of their software and systems.

· Security Zone ·
Free Resource

To understand the current and future state of the cybersecurity landscape we spoke to and received written responses from 50 security professionals. We asked them, "What suggestions do you have for developers to improve the security of their applications and data?"

In part one we learned that secure development practices, audits/scans/tests, and education/best practices were the top three things developers could do to improve security. Here's the second set of suggestions:

Tools

  • Know how to use your tools. Use multiple tools that provide multiple perspectives. Don’t rely on a single solution.
  • As new models evolve, the tools of the past need to adapt as well. Developers need to work with their information security colleagues to facilitate security's "Shift Left" to the beginning of the development cycle. Shift Left is a well-understood concept in developer circles, and it needs to become just as familiar from a security perspective in order to identify and remedy potential security issues with applications before they move into production and throughout the development cycle.

    However, and this is the responsibility of the security team and not developers, an organization must also “Shift Up” to focus on its new priority — protecting the application layer. Shift Left cannot fully address the new security issues that containers and serverless functions can create. For example, it does not provide for effective detection and incident response in the case of a new zero-day attack on a running container. Effective incident response requires identifying the incident, understanding its causes and potential effects, and then making a decision on whether or not to take action — something that is only possible with controls over the runtime environment.
  • To compete in the digital economy, enterprises are increasingly competing on time-to-market by moving to development methodologies like DevOps. The pace of change observed in digital solutions necessitates that security is built-in instead of bolted onto applications. Developers should leverage security tools and frameworks purposefully built to seamlessly integrate into the development pipeline.

    One particular area of focus is the use of open source or third-party libraries with known security vulnerabilities that impact the risk posture of the application. With the growth of infrastructure-as-code and serverless functions, developers should verify that code impacting the operational environments go through a risk-aligned security verification, including both automated and manual techniques.

APIs

  • Use RESTFUL APIs to know how your data will be operated on, share with people that there’s no black magic to it — as applications scale, the RESTFUL API provider will also scale. Legacy solutions tend to have a lot of black magic. Ask for security audits and ask for fudge testing. Build a model for data security. Adopt a data-centric approach to security and use APIs that can be explained.
  • API OWASP top 10. Understand the top 10 threats for APIs. At the same time, you cannot expect developers to own security. A greater security mindset will help them be mature but still look to security teams to enhance security on top of it.
  • Design, build, and connect to your APIs from the start with security in mind. Implementing an API-aware WAF can also go a long way in mitigating security issues and providing visibility into flows. Closely review third-parties and, wherever possible, replace numerous point solutions with more comprehensive products that offer an integrated security approach. Implement regular vulnerability scans, penetration tests, and security code audits.
  • Have security as part of your core design framework. Provide full logging of all activity to application. Use the SSO integration with the rest of the enterprise and don’t store any passwords within the app. Use REST API with token registrations. Use a collaborative design with automated deployment for continuous integration and delivery of data flows. Look to an intelligent pipeline that monitors dataflow in real-time and automatically detects policy/behavior drift. Use SLAs that enforce standards for data availability quality and security. Quickly update data flow in response to new sources and new user data. Run open source vulnerability scanning tools on the application.

Partner With Security

  • The key thing is to partner with security groups. Developers know there is no shortcut. Developers know how to develop a program, but they also need to have the right partner in the security group in order to fully understand how to develop a program correctly. Everyone has the same goals. You need a team to accomplish them.
  • As the technical landscape has become increasingly more aggressive, and enterprises need to keep up with their competition, slowing down isn’t an option. Unfortunately, both DevOps and Security teams have had a difficult time getting on the same page during this transformation. A recent DevOps survey conducted by CyberArk found that 60% of respondents felt that “security teams lack the technical expertise to engage meaningfully with their developer and DevOps counterparts.” Interestingly, DevOps and security teams agree on this point — almost as many security/IT respondents felt that security needs more technical expertise as DevOps respondents.

    Previous research also found that only 41% of security and DevOps teams are well integrated throughout the application development process. Vast improvements can be made from facilitating a cultural shift between developers and security to ensure that security isn’t sacrificed for the sake of speed. Here are a few best practices:

    1. Transform your security and DevOps teams into partners. Silos need to be broken down. Developers should embrace that security teams have something important to offer in terms of best practices and know-how. Security teams embrace new ways of working in the “fast-flow” of modern software engineering. Train developers to “think like attackers,” and set up formal systems to ensure Dev teams understand security risks and implement good security practices across the organization. Meanwhile, train security pros on development tools and techniques. Even if the actual coding of applications is done by DevOps practitioners, the security team will need to be able to credibly communicate with them.

    2. Include security early on. Security needs to be built into development processes early on, and that can only happen when security and development teams collaborate. DevOps leaders should include representation from security early in key initiatives and decisions. Security teams need to get their minds around incremental, continuous delivery, as a method for improving security that will reap better results over the longer term. By collaborating earlier in the development processes, security can be improved without impacting DevOps velocity.

    3. Evaluate and continually measure the results: Security, development and DevOps teams can build consensus by sharing objectives and metrics (e.g., Are secrets being found in code in public repositories? What percent of application secrets have been secured? Once secrets are secured, how frequently are they being accessed?). This helps security teams speak the same language as DevOps and helps DevOps teams achieve their scale and automation goals. In most cases, improving security happens through many incremental advances. Teams should highlight each success and then build and expand from them. For example, organizations can use metrics to show how much of the attack surface has been addressed or how well each DevOps team complies with security requirements. Aim to have some initial successes to demonstrate security and efficiency gains and branch out from there.
  • Developers understand their unique position between the product and their security teams. The circumstances that arise due to that — the repetition of code errors and the lack of security knowledge — should be a forcing function for developers to look to automation and community as much as possible to improve the security of their applications and data. I recommend that developers implement fuzzing, code analysis and dependency analysis to prevent vulnerabilities as much as possible, and to use runtime monitoring, ASLR, and moving target defense to mitigate exploits. Outside of these tactical implements of change, the most important thing developers can do is to push for a culture change. The enterprises that have the most success in application and data security have appointed security champions on teams, who coach others on how to write secure code. They celebrate successes — when a vulnerability is found and fixed, they make sure that everyone knows. This isn’t just within the doors of your own organization. It’s with the greater community at large. Security will only improve when the community is part of the development and security process.

Governance

  • Open up and tag information for better metadata management. Add context to the tag around security and sensitivity in the metadata management system so security tools can take advantage. It comes down to the data governance and how to define policies like metadata management, what it is and who has access, and what are the concerns around it. Developers need to integrate with security.
  • Protect the brand and your customers' trust. Ensure compliance with governance, regulations, and privacy. Know the basic tenets of software security. Understand the technology of the software. Develop software with secure features.

This is the second of three articles which share what IT professionals thought developers could be doing to improve the security of their code and applications. Take a look at Part 1 and Part 3.

Here’s who shared their insights:

Topics:
security ,secure development

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}