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

Most Common Security Flaws

DZone's Guide to

Most Common Security Flaws

Read on for insights from executives from some of today's top companies on how the need for better security is affecting the industry.

· Security Zone
Free Resource

Address your unique security needs at every stage of the software development life cycle. Brought to you in partnership with Synopsys.

Awareness/Education/Knowledge

  • Awareness. Security as a habit. People know what’s good and bad but it’s not part of the daily process. The human being is the weakest link. We need to educate and make people more aware. Most attacks are due to human error. Help them understand the value and depth of the challenge.

  • Plain text data must be encrypted.
  • Developers are not security aware. Training does not focus on security testing, nor what to do with the results. Provide security training to the development team. SQL injection and cross-site scripting are very common, with 30% of web apps having SQL injections and 50% having cross-site scripting. We need to take these flaws seriously.
  • Lack of awareness in top management. Lack of experienced professionals. Therefore, companies need to move to managed services.
  • Insecure communication and information not being secure because developers/managers do not know how to use the software properly or interpret the results. There’s not enough effort made to secure the data and communications provide an additional layer for monitoring and visibility to confirm the information is still protected.
  • Encryption is great; however, we’ve seen customers connected directly to malicious websites who can use the tunnel and encryption keys to get to the endpoint. You need visibility into communications to verify they are properly protected.
  • Lack of awareness, lack of skills, and no clear KPIs based on code security. Developers are unfortunately measured only by speed and functional quality and code security is only now starting to become more relevant.

Poor Practices

  • Failure to stay on top of bugs in third-party software. Call the encryption algorithm correctly. Correct problems in libraries. People still transmit data in the clear. HTTPS and SSL are now becoming standard – or should be. For the disclosure process, when you find problems, disclose the information to the owners and the end users. Do not make a public statement without giving the originating company an opportunity to fix the vulnerability.
  • Insecure coding practices and accidentally leaving behind private crypto keys.
  • Everything starts with hygiene and misconfigurations and systems not being properly patched. This is consistently the “low hanging fruit.” We then map the critical infrastructure by looking at network traffic and user activity. Users always want to get to the internet. Determine if they are using a normal path to do so or if they're using a workaround that circumvents security and introduces risk.
  • Time to market is critical for clients. It’s the number one reason companies are moving to the cloud using DevOps, CI, and CD to drive customer intimacy and customer experience (CX). The risk is that security controls can fall through the cracks. It becomes an afterthought. This is more common in DevOps where security is not built in from the beginning. Developers are responsible for configuration of the network and infrastructure. Security best practices may not be followed due to speed to market since developers are responsible rather than security professionals.
  • Not knowing where all your information and data is. Security professionals work outside of the business unit, causing the business executives to not view security as an integral part of the organization. We must stop letting executives play the “victim” card. Make informed decisions about what investments should be made in security. Ensure senior management and security are on the same page. This typically doesn’t occur until the first major breach. Put your security dollars where the data is. 
  • Lack of policy and procedures for developers and security professionals to follow throughout the SDLC.
  • Despite the delivery gap which hurts IT, the business still needs to keep going forward. Now companies are viewing IT as a blocker rather than a business partner, the broader business too frequently decides to take matters into its own hands. Departments like marketing, sales, and finance start producing and procuring their own solutions outside of the central IT department, creating the rise of shadow IT. Connecting shadow IT apps to sensitive data with insecure point-to-point connections compounds this problem.

Volume/Velocity

  • The sheer volume of incidents. More demand for compliance, reporting, board demands. The proliferation of toolsets to get the job done.
  • Budget limitations. The volume of security choices (> 1,500) and suppliers. Prevention is not enough. There is limited trained staff and limited access to staff. As such, solutions must be easy to learn and operate. We’re able to see what attackers are doing. It works, it’s accurate, and there are no false positives.
  • It's difficult keeping up with the rapidly changing environment and to get your arms around account sprawl and cloud sprawl. If security is not part of the process, it’s hard to know what’s going on in each area and how sensitive the information is. A simple inventory is a big challenge. Visibility is the challenge. It's hard to know from the outside what’s going on if you don’t have visibility.
  • Trying to scale tools in fast moving ecosystems. Most commercial security tools require someone trained in application security to configure the tools and read the results. Developers can set up dynamic analysis, like penetration testing, but they may not understand the results of the tests. You may need someone from security to help them understand how to interpret the results. Static analysis and tooling of the source code require a security person to run and analyze. Tools give more results than you need, i.e. false positives. This discourages developers and causes them to lose trust in the tools and the tests.
  • Transfer of application infrastructure and the security infrastructure is not sufficient in approach or products. You cannot rely on a single perimeter solution. Companies feel like they are running too many tools (dozens form a patchwork defense). Ability to integrate and streamline security in the organization is key.

Risk Assessment

  • Risk = threats x vulnerability x assets. Know what’s on your network. Track, manage, and control BYOD. Frequently audit for common vulnerabilities. Think about internal risk. Too much malware cannot be detected. It can take a year to know if you have remote access Trojans on your network.

Visibility

  • Lack of visibility into, and control of, cloud applications. CASB was born because one of the most common issues in security is that traditional legacy vendors fail to adapt to the cloud and its security needs. Cloud-native applications can extend traditional threat protection to the cloud to which people have become accustomed. We’re seeing the convergence between traditional and cloud security. Cloud security will become a subsidiary of traditional network perimeter security providers.
  • Lack of ability to monitor threats in real-time at the speed and scale at which they are coming today.

What are the most common issues you see affecting security?


Following are the executives that shared their perspectives on this question:

Find out how Synopsys can help you build security and quality into your SDLC and supply chain. We offer application testing and remediation expertise, guidance for structuring a software security initiative, training, and professional services for a proactive approach to application security.

Topics:
security ,cloud security ,security risks

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}