Most Common Security Fails (Part 3)

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 are the most common security fails you see today?"

In Part 1, the lack of fundamentals, training, and vision were covered. In Part 2, a lack of strategy, up-to-date technology and tools, patching and data best practices were provided. The following are the responses that fell into the "other" category:

• We still see many sensitive systems that rely only on passwords. This is because mainstream MFA solutions are either difficult to implement, because they require some form of integration with each protected system (often requiring software agents, proxies, SDKs or configuration changes), or because they simply do not support these systems. But passwords can be easily hacked, stolen, or breached, which makes them an unreliable security measure.
• The most common is the vendors. A lot relies on core security technologies. You cannot just rely on one source of data. Validate why and what a flare-up means. What does the data mean? Bring a context to the event. The extent of the attribution is not meaningful. What is the context? You need to have a good mix of vendors and triangulate the events.
• The cost to implement a proper and effective solution to protect your data can be quite expensive to acquire and maintain. If you cut costs, you can reduce effectiveness.
• A big one is open inbound ports. For one device — say, a server — to push data, another device (i.e. an IoT device, a smartphone) must be listening. In a traditional model, the listening device will open an inbound port and wait for data to be pushed. While this can work in some scenarios, it is a massive risk as these ports must remain open indefinitely. The security risks of leaving inbound ports open include malware infections, modification or theft of data, DoS attacks, and arbitrary code execution. Think this way — any device on the Internet with an open inbound port will be attacked. It’s a matter of when not if. Devices connected to a secure network infrastructure should make only outbound connections. These connections are not vulnerable to the kind of attacks that open inbound ports are. To support this design pattern, you need to use a publish/subscribe communication design so devices can send data bi-directionally.
• Many data breaches share the same origin stories. A laptop was left behind at an airport or in a taxi. Or, the device password was written on a sticky note where anyone who looked might find it. Or, an endpoint didn’t have encryption in place. Unfortunately, the end results of these poor practices are just as common.
• 1) The most common and risky scenario we see is enterprises not protecting ALL their applications, APIs and microservices. Organizations no longer have just a few apps with a few paths to access. Instead, they have many apps, each often dependent on and delivered through a myriad of APIs. All too often, organizations deploy protection solutions to their most critical applications (main website, e-commerce apps, portals) which intuitively makes sense but in reality, leaves them seriously exposed when not protecting all the other apps in their portfolio (“lock the front door but leave the garage and patio doors open”). This is often a result of heavyweight, legacy security solutions that are burdensome to broadly deploy and maintain. 2) Another scenario we see all too often is the tendency to spend budget and allocate skilled teams to implement, manage, and tune security solutions while not looking at technology and solutions that should actually be unburdening those teams. The “throw more humans at the problem” is an even bigger challenge with a very real talent/skills gap in the cybersecurity industry.
• The most common security fails we see are side effects of the dynamic complexity and scale of cloud and the inability of humans to manage it. Continuing to rely on human processes for security and compliance in the cloud make a major security incident a near certainty.
• With thousands of locations without IT resources in the field, the likelihood of a misconfiguration is great.
• Spooky spy agencies to plumbing shops. Larger organizations have a large security team. Mid-size need help with a secure by default environment. Careless removal of media. Never change passwords, selection of an insecure password.
• 1) When talking to our customers, many cite the challenge of dealing with the dynamic nature of the environment as new services are automatically provisioned to meet demand. The IT security team no longer has adequate time to evaluate risks and provide late-stage guidance to ensure compliance. Not only has the window to properly review the application and its infrastructure has become much shorter, so has the time for overall systems testing as services are updated independently on a much more frequent schedule. 2) Another challenge is the loss of complete control over the physical network infrastructure as services are moved across data centers in different locations, or when the IT operations and security teams don’t even know where they are running, as is the case in serverless models. 3) Enterprises are realizing that traditional security tools cannot handle the velocity, scale, and dynamic networking capabilities of containers and serverless infrastructure. At the same time, with less knowledge of the provenance of code that is being reused, there is potential for new threat vectors. Attackers may leverage a weakness or a vulnerability in base images used for containers, outsourced libraries, and OS dependencies or in serverless function code; or take advantage of vulnerabilities inside the cloud infrastructure’s permissions settings to reach services or networks that contain sensitive information.
• The most common security shortcomings fall into two categories: Failing to implement the knowns and failing to detect the unknowns (or the “black swans”). The knowns have been discussed in detail following every major security breach and are publicly available, yet organizations fail to take proactive measure and implement them. Examples may include:
  • Identifying the “Crown Jewel” assets
  • Building an orchestrated response plan, taking into account business risks
  • Improving detection capabilities and log retention policies
  • Mapping all entry points for third-party vendor access to the environment
  • Deploying security patches on a regular basis
  • Signing retainer agreements in advance
• The “black swans,” on the other hand, require a slightly different approach. As defenders, we tend to be one step behind and must not let what we know blind us. Mature organizations take a proactive approach to them by challenging the status quo. This is normally done through cyber threat intelligence missions and advanced attack simulations at various levels throughout the organization.
• 1) The most common security fails today include incorrect assumptions about the hosting provider's scope of security, a false sense of security, and neglecting to educate staff properly. 2) Many website owners have incorrectly made the assumption that their website hosting provider is protecting every aspect of their website from compromise. While this may be true in some cases, it is very uncommon and not priced to compete with traditional shared hosting. In most cases, the hosting provider is responsible for securing its hosting infrastructure as a whole. You are more or less a tenant renting an apartment — the host provides the four walls, the locks, and the keys. However, making sure you're keeping your windows and doors closed and locked is the tenant's responsibility. As we add more features and complexity to our web applications to deliver a richer experience to our visitors, we're often also increasing the attack surface of our websites. Securing these customizations involves leveraging our own security solutions, tailored to the unique functionality of our web applications. 3) Another major shortcoming that we often come across is the false sense of security — the common misconception of being "too small to hack." This mindset could not be further from the truth of the matter, which is that close to half of all cyberattacks worldwide target small businesses. Following a breach, most small businesses never recover, the majority going out of business within a year. There is no shortage of adversaries looking for easy wins, and small businesses are all too often the low hanging fruit. 4) Last and certainly not least is neglecting to educate staff on how to do their part in preventing a breach, and what to do in response to a potential breach incident. Your security is only as strong as the weakest link in your armor, which is often an insider with access to sensitive information. Leviathans of the industry have been brought to their knees by an unwitting staffer clicking a link within an email, or by a clever social engineer "having trouble accessing their company email." Businesses need to train their staff on how to be an effective human firewall, as well as the proper procedures following a potential breach event.
• Security is about building trust as much as it is about defense-in-depth. Too many organizations are still sweeping security vulnerabilities under the rug when they should be thinking about how to use transparency to build customer trust. Of course, it is a fine line to balance between being transparent and maintaining opacity where it makes sense. Some of the biggest corporate breaches in recent years have been reported months and even years after the incident has already occurred, and that is a complete fail for building customer trust. The customer will wonder what else the corporation is trying to hide, and will move on to a competitor, most likely.
• One of the biggest areas of friction remains to bring together security and development operations. For the last five years, the most major cloud and DevOps surveys cite this as a top-ranked challenge for organizations, as IT security professionals and developers often have different areas of responsibility, differing technical capabilities and they typically work in operational silos. Without aligning goals and tightening communication, you see stand-offs between groups and typically one of two outcomes. First, there could be delays in the product or key infrastructure-related or launch dates – especially around production or sensitive systems. Second, there may be unchecked security issues that the leave the company at risk. Both of these scenarios are a result of unmanaged technical security debt or lack of focus on the release date as the date of value delivery to the business by the DevOps team. It doesn’t have to be this way. Speed, velocity, and resiliency do not need to be sacrificed in order to be secure and have more stakeholders at the table. From a cultural standpoint, 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 will have to embrace new ways of working and sometimes learn a new lingo to work in the “fast-flow” of modern software engineering. Security needs to be built into the development processes early on, and that can only happen when security and development teams collaborate as true partners. 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. The biggest missing influencer in this whole process is ultimately the biggest stakeholder – the business. All or nothing approaches, which many times lead to the “sidelining of security”, are resulting in security failures being reported in the news each day, and that’s terribly bad for business. Digital transformation initiatives are stalled because of security issues, and that’s incurring a massive opportunity cost. The business needs to lead from the top and consistently realign the teams toward the common goal, taking the company into a secure, velocity-focused future.
• At the root of the security, crisis is the lack of coordination between developers, security researchers, and the security community at large. Developers are constantly pushed to deliver new features rather than to secure existing code, and legacy security tools only slow them down. Security researchers do much of their work manually, typically conducting manual security assessments for every big release. They spend hours on repetitive work, rather than creatively looking for new problems and solutions. The security community exchanges its findings through blog posts and conferences, but there’s no way to share knowledge in an automated, easily re-usable form. This leads to broad duplication of work – because there is a lack of avenues to easily share security expertise, researchers and companies are left starting from scratch every time they vet projects. Consequently, the same vulnerabilities show up again and again, with researchers unable to connect the dots. This is where automation becomes key – relying solely on manual testing is traditional but outdated. Another issue developers face when attempting to secure their code is that they often lack certain security knowledge or understanding of how vulnerabilities could potentially be exploited. This specialized knowledge and tooling are usually found only among members of a company’s security team. The developers are forced to rely solely on their company's security team for this information, and, therefore, have little control over the state of the security of their projects. For example, when working on open-source projects, contributors might not have complete context-specific knowledge of the entire codebase and inadvertently introduce code that leads to security vulnerabilities. If teams are to avoid the types of “fails” that are common, they’ll need to seek tools that go beyond their own brainpower.
• There are several very common ones that sophisticated customers are trying to move away from, but they still happen. Using static, long-lived or shared credentials. This is especially problematic when old credentials or accounts are forgotten, but access it never turned off. Another one is treating networks and systems like they’re impenetrable — or low-trust networks like they isolated, private data centers. Some organizations settle for remediation instead of prevention, which is a mistake. Other organizations don’t separate roles and responsibilities and given everyone admin privileges to every system. They should instead create silos, so DBAs, for example, only have access to the data and permissions related to the databases they need. Finally, it’s also a mistake not to think applications are flawless, when in fact they leak sensitive information as well.

Here’s who shared their insights:

• Josh Mayfield, Director of Security Strategy, Absolute
• Jim Souders, CEO, and Anne Baker, V.P. of Marketing, Adaptiva
• Steven Aiello, security and compliance solutions principal, AHEAD
• Gadi Naor, CTO and Co-founder, Alcide
• Omer Benedict, Senior Director of Product Management, Aqua Security
• Tom Maher, CTO, Asavie
• Gaurav Banga, CEO and Founder, Balbix
• Nitzan Miron, V.P. Product Management, Application Security Services, Barracuda
• Cam Roberson, Director of the Reseller Channel, Beachhead Solutions
• Anurag Kahol, CTO, Bitglass
• Syed Abdur, Director of Product Management and Design, Brinqa
• Laura Lee, Executive Vice President of Rapid Prototyping, Circadence
• Andrew Lev, CEO, Cliff Duffey, Founder and President, Bethany Allee, Vice President Marketing, Cybera 
• Brian Kelly, Head of Conjur Engineering, CyberArk
• Doug Dooley, COO, Data Theorem
• Jason Mical, Cyber Security Evangelist, Devo Technology
• OJ Ngo, CTO, DH2i
• Tom DeSot, EVP CIO, Digital Defense, Inc.
• Chris DeRamus, Co-founder and CTO, DivvyCloud
• Alan Weintraub, Office of the CTO, DocAuthority
• Tom Conklin, CISO, Druva
• Anders Wallgren, CTO, Electric Cloud
• Satish Abburi, founder, Elysium Analytics
• Sean Wessman, Americas Cyber Markets, Sectors and Business Development Leader, EY
• Ambuj Kumar, Co-founder and CEO, Fortanix
• Josh Stella, co-founder and CTO, Fugue
• Kathy Wang, Senior Director of Security, GitLab 
• Amith Nair, VP Product Marketing, HashiCorp
• Mike Puglia, Chief Customer Marketing Officer, Kaseya
• Nathan Turajski, Director of Product Marketing, Micro Focus
• Gary Duan, Chief Technology Officer, NeuVector
• Gary Watson, CTO and Founder, Nexsan
• Stephen Blum, CTO and Co-founder, PubNub
• Chuck Yoo, President, Resecurity
• Roey Eliyahu, CEO and Co-founder, Chris Westphal, Head of Product Marketing, Salt Security
• Sivan Rauscher, CEO and Co-founder, SAM Seamless Networks
• Igor Baikalov, Chief Scientist, Securonix
• Oege de Moor, CEO and Co-founder, Semmle
• Dana Tamir, VP Market Strategy, Silverfort
• Logan Kipp, Technical Architect, SiteLock
• Albert Zenkoff, Security Architect, Software AG
• Tim Brown, V.P. Security Architecture, SolarWinds
• Todd Feinman, Co-founder and Chief Strategy Officer, Spirion
• Tim Buntel, VP of Application Security Products, Threat Stack
• Andrew Useckas, Founder and CTO, ThreatX, Inc.
• Joseph Feiman, Chief Strategy Officer, WhiteHat Security
• Vincent Lussenburg, Director of DevOps Strategy, XebiaLabs
• Robert Hawk, Operations Security Lead, xMatters