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

DZone Research: Should Developers Be Responsible for Security?

DZone's Guide to

DZone Research: Should Developers Be Responsible for Security?

We talked to lead executives in software development about what developers need to do in regards to security. Here is what they had to say.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

To gather insights on the current and future state of security, we talked to 47 executives from 43 companies about security in their own organizations and for the clients with whom they are working. Given all of the breaches that have appeared in the news and the enforcement of GDPR, response to this topic was unlike any we have seen for previous security research guides.

We asked them, "What do developers need to keep in mind when building secure applications?" Here's what they told us:

Security By Design

  • They need to embrace security early in the process and during the design to have it fully automated and integrated into their SDLC.
  • Treat security like the nucleus and most important feature of your product. If security isn’t the center point, it’s difficult to figure out how to secure after the fact.
  • Plan for any system you build to be responsive to being hacked. Also, you need to think about security and privacy by design while building these applications.
  • It is important to look at a system and think about how that would break. How would someone use this poorly? Don’t make assumptions that what you’re writing about will not be attacked. DDoS botnets have been used to attack banks. Think about how I can break it. It is critical for security to be a forethought rather than an afterthought.
  • Buffer in time for security and seek security awareness training. This means that you follow secure development practices and interact with security engineers. Read about security attacks and see if that could impact what you are working on. You can look at the reverse engineer of the attack and the lessons you can extract. This can be done by putting barriers in place to make it hard for the hacker. Adding layers of defense can also make it more painful for the hacker. And, these assets are going to be different for each application. It's also worthwhile to step back and think about what you are protecting, collecting, and any key actions as inputs and outputs. Are you making it difficult to hack or change?
  • Developers need to understand the basics of security/privacy by design. Think about and plan for security threats and mitigations (threat modeling) during the architecture design phase. This will go a long way in proactively avoiding vulnerabilities rather than fixing and rearchitecting at a later stage. Developers should have good knowledge of security strength/pitfalls in any new programming language or framework that they adopt.
  • 1) Always think about the data you’re dealing with. Define and make sure every developer understands “data security levels” and what types of protections should be associated with different types of data. 2) Think about security before you start writing code. Perform engineering design reviews as part of your development process. It doesn’t have to be crazy, just think creatively like a black hat hacker would. Keep asking yourself “If I wanted to mess with this product and make my code do something it shouldn’t, what are some things that could go wrong? What’s the most catastrophic effect that it could have?”

Best Practices

  • There are three well-known security frameworks every developer should follow. These frameworks are a collection of rules, techniques, and processes that guide development organizations and frequently provide resources that can be applied. Each has a different focus, but all are fundamentally oriented around security — Microsoft’s Secure Development Lifecycle (SDL), Open Web Application Security Project (OWASP), and Industrial Internet Consortium (IIC). When we lump together security features into applications, we’re concerned with topics like authentication, access control, confidentiality, cryptography, privilege management, and all the other items on the CISSP exam. This stuff is hard to get right.
  • Know your target. It is so important to understand the infrastructure you are deploying to. Therefore, it is crucial to know and understand users and use patterns to see what’s normal and what is not. You want to understand how systems within the organizations interact. And, you want to put the brand before the job.
  • Think more about encryption. This is not complicated, it's been around a long time. You want to decrypt at the last possible moment and as close to the user as possible. You want to find out who has keys, where it could be exposed, where it could be leaked, and what happens if it is lost.
  • Profiling. Practice more profiling as you get more information out of the network about the customer, device, and account.
  • No clear text. Any sensitive data is never in clear text. Therefore, sensitive data needs to be defined for each company.
  • Code defensively. All the risk is around remote command execution vulnerabilities. Do not have a casual attitude towards open source. You need to take personal responsibility. This is why it is essential to protect yourself and respond to intrusions at the boundary. Developers like being in control and helping themselves. They do this by internalizing the importance of taking care of the PII. Do others need to see that information? Turn your attention toward a positive constructive solution.
  • Avoid basic mistakes – injection and overruns. You need to know what is it that you’re trying to protect and from whom? Am I looking at the hacker or malicious insiders? From there, you can start to produce a solution. You need to recognize that security is about security in layers.
  • Also, you need to understand that this is a team sport. Everyone has to think about security. Does data at rest need to be encrypted? How do you know the endpoint is secure? What tools should I be using? Be aware, learn, understand, read, and be curious.
  • Think about security. A key does not equal security. Credentials can be stolen. Everything is under attack. Hackers can probe all access points.
  • 1) Network topologies are changing as the world has moved beyond the traditional perimeter our firewalls and intrusion detection systems have protected. An increased focus needs to be put on the data and layer 7. This includes a focus on items such as API security and middleware communication. This is so that we can protect key components that makeup solutions stacks. The developer’s job does not end when their chosen vulnerability tool reports no issues. They should not become complacent, as the vulnerability tool is only one perspective. In a mature development program, there should be a multi-layered security approach that includes risk assessment and modeling, developers’ training, scanning and auditing third-party components, and ongoing operational monitoring and change management. 2) Oftentimes, there are issues outside of the source code itself that are equally risky. For example, perhaps the SaaS incident management system or cloud hosting provider does not have effective identity management, or their API keys are posted in error somewhere publicly accessible. 3) Managing "secrets" properly (e.g. AWS keys, passwords, etc.) also contributes to reducing accidental leakage and tends to integrate more with automation toolsets. This also helps to integrate KPIs within development workflows to builds up confidence so that we only trust the components that we should trust. 4) Also, given the sprawl of exceedingly good open source projects, re-inventing the wheel internally is probably not what people want to do. Developing security quickly on a table corner is bound to bring issues sooner or later, so better start eyeing on code that professionals do for a living. But, developers should audit this open code, having in mind there are other hundreds of people that might be taking advantage of it.
  • 1) Secure coding — use the latest coding conventions and avoid using deprecated frameworks and functions. 2) Perform static and dynamic analysis of your code to find security vulnerabilities. 3) If you use open source projects, make sure you review the code that you integrate into your product for security risks. 4) Use the latest standard encryption for all communications and authentication mechanisms.
  • Developers who don’t know how to write good, secure code need to understand the basics of application security. Application security knowledge is absent in the broader development community. Offer a security development program made up of seven eight-hour workshops with five thousand signed up and 500 passed the rest. Developers have awareness around the lack of application security and we need to provide bridge-the-gap training.
  • Building secure applications can be achieved only if developers make secure development principles a part of the way they think and work. Studying and integrating OWASP is a great place to start.
  • Have developers have an understanding of security and broader infrastructure. It's important to understand what you are writing for and have general security awareness. Also, you want to understand secure coding practice. This is what you are building and why you are building it — understand the big picture.
  • So many things! Here are some highlights: 1) Are you hashing your passwords using scrypt or Argon2? What work factors have you configured? 2) Is your infrastructure running in isolated VPCs when deployed to cloud service providers like AWS? 3) Are you taking advantage of the new HTTP security headers — Strict-Transport-Security and Content-Security-Policy? 4) Are you taking steps to avoid cross-site request forgery attacks (CSRF)? 5) Are you taking steps to avoid introducing cross-site scripting attacks (XSS)? 6) Are you logging sensitive information? Passing credentials in query parameters, etc.? 7) Are you using multi-factor authentication? 8) Are you analyzing usage heuristics and running them through machine learning pipelines to detect services abuse and other bad behaviors? 9)Are you using SSL? Are you using a significantly modern version of TLS?
  • It’s unrealistic to expect developers to all become security experts. But there are better practices that should be followed, and organizations should find ways to adopt ones suitable to their environment and instill them in development. In today’s agile environments, the most important thing developers should remember is that shortcuts of convenience, or lack of adherence to best practices, are riskier than ever because code can make it into production with less scrutiny. For example, using unvetted open source code is irresponsible, because it may contain severe vulnerabilities or malware. Shortcuts, such as hard-coding RSA keys into code for the convenience of testing, end up in the production environment too often, putting credentials to sensitive data and systems at risk. An examination of severe security incidents and breaches almost always demonstrates a series of failures that led organizations to that point, rather than a single point of failure. So, while a single developer mistake may not in itself lead to a breach, it may well be a contributing factor, without which the breach wouldn’t occur.

Other

  • Look for tools to help them integrate AI and ML to build components that allow applications to be more secure in the app itself. It's better to play with other security tools out there. Data collecting can be considered competent and usable for other security solutions.
  • Know the threats and vulnerabilities specific to your frameworks and technologies. Understand how the software you are building can be attacked and compromised. Microsoft built a card game that encourages SW dev teams to think about abuse cases in a non-threatening way. Asynchronous way to think about vulnerabilities specific to their technology. Incorporate security earlier in the SDLC improves throughput. Over several iterations higher throughput than when started. Worked with two groups at Microsoft to measure as well as banks. It's an investment that will pay dividends later on.
  • What are the platforms I need to run on to provide the security I need? The cloud has evolved away, but, on the embedded side, usernames and passwords need to be replaced with certificates.
  • Great question. Looking cool is nice, but solving the real threat is nicer! There are so many tools in the market that make great claims but somehow fail to live up to expectations. Perhaps I have worked in Germany for too long; however, there is a stereotypical view of Germans that they pay attention to detail and to process, obsessively. Our development team is immersed in the details of the problems they are solving and the customer experience that follows, but more than that they are adapting to new threats daily. Our number one challenge is to keep abreast of the threat landscape and adapt fast.
  • Grab DevSecOps with both hands. Automate. If you’re working on IoT write a five-line piece of code to change the default password. Know what secure code is.
  • Many developers are focused on delivering functional code as fast as possible. They often forget or are told it’s not their responsibility, to secure the environments their code is running on. The security of the environments is as important as the delivery of the code. For example, a container is built to run a microservice, what OS is in the container? Is it secure? Is it patched? Is it configured correctly? These questions and answers are pertinent since all containers have an OS at their core.
  • Be paranoid.
  • No one thing. Traditionally we have seen any application running within the perimeter in a trusted environment. Build as if your application is running on the internet. If they build with that mentality, that’s the starting point. Lethargic approach to security. Think it’s handled by another team. We don’t have to pay as much attention. It’s common to see developers using passwords. It’s not like an alarming thing but they need to change how they are thinking. We are not in an untrusted zone.
  • Don’t reinvent the wheel. Use the right tools and frameworks to use what the people before you have done. Use a framework or DB abstraction layer that you know does not have SQL injection. Use what’s been battle tested.
  • A lot you can do from a secure development perspective. Not every developer is a security expert. Facing deadlines. Make mistakes. Make sure you’re taking advantage of automated tools and view as an enabler and not a threat to know what they build will be secure.
  • Know and define upstream and downstream clients of the application service and be able to isolate those interactions so attackers can’t get in. Be careful of open source software used in applications and make sure each new update is carefully scanned.
  • You have an obligation to produce secure software. Reach out to your security teams for help. Be a facilitator for collaboration. Also, get as much training as you can on security frameworks and secure coding practices.
  • Know you can be the weakest link. Follow architecture. It’s all about the APIs. Companies should always have password managers for their own employees. In control of all hardware and cell phones. Security is what developers develop and how they behave in the environment they are in when doing so.
  • Developers must always consider that there may be serious vulnerabilities in the open source code or in libraries from package managers they are using. Developers will have to work to ensure the integrity of that code or bring in a security expert who can.

Here’s who we talked to:

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,security by design ,research

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}